[JBoss JIRA] (DROOLS-5681) ByteArrayResource bytes attribute read/write twice
by Sylvain Lemoine (Jira)
[ https://issues.redhat.com/browse/DROOLS-5681?page=com.atlassian.jira.plug... ]
Sylvain Lemoine updated DROOLS-5681:
------------------------------------
Summary: ByteArrayResource bytes attribute read/write twice (was: ByteArrayResource byte attribute read/write twice)
> ByteArrayResource bytes attribute read/write twice
> --------------------------------------------------
>
> Key: DROOLS-5681
> URL: https://issues.redhat.com/browse/DROOLS-5681
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Sylvain Lemoine
> Assignee: Mario Fusco
> Priority: Major
>
> When using Java standard serialization mechanism, we can see that ByteArrayResource is now written twice
> in ByteArrayResource
> {code:java}
> @Override
> public void writeExternal(ObjectOutput out) throws IOException {
> super.writeExternal( out );
> out.writeObject( bytes );
> out.writeObject(this.encoding);
> }{code}
> And super class writeExternal:
> {code:java}
> public void writeExternal(ObjectOutput out) throws IOException {
> //...
> out.writeObject( bytes );
> }{code}
> It works as it also read twice in ByteArrayResource#readExternal and ByteArrayResource#writeExternal.
> Anyway, moving the bytes attributes from child class to super class broke our project serialization as we rely on java serialization for our KieBase resources. Seems ok as we'll address it by some tweaking on serial uid, but fixing this issue (read/write once instead of twice) will also break sdeserialization for project which rely on it from 7.34.0.Final.
>
> Don't know if it's okay to fix it in the next version. I can make a PR for this case.
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (DROOLS-5681) ByteArrayResource byte attribute read/write twice
by Sylvain Lemoine (Jira)
Sylvain Lemoine created DROOLS-5681:
---------------------------------------
Summary: ByteArrayResource byte attribute read/write twice
Key: DROOLS-5681
URL: https://issues.redhat.com/browse/DROOLS-5681
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.43.1.Final
Reporter: Sylvain Lemoine
Assignee: Mario Fusco
When using Java standard serialization mechanism, we can see that ByteArrayResource is now written twice
in ByteArrayResource
{code:java}
@Override
public void writeExternal(ObjectOutput out) throws IOException {
super.writeExternal( out );
out.writeObject( bytes );
out.writeObject(this.encoding);
}{code}
And super class writeExternal:
{code:java}
public void writeExternal(ObjectOutput out) throws IOException {
//...
out.writeObject( bytes );
}{code}
It works as it also read twice in ByteArrayResource#readExternal and ByteArrayResource#writeExternal.
Anyway, moving the bytes attributes from child class to super class broke our project serialization as we rely on java serialization for our KieBase resources. Seems ok as we'll address it by some tweaking on serial uid, but fixing this issue (read/write once instead of twice) will also break sdeserialization for project which rely on it from 7.34.0.Final.
Don't know if it's okay to fix it in the next version. I can make a PR for this case.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Ranabir Chakraborty commented on WFLY-13828:
--------------------------------------------
Hello, [~mgrossmann] thank you for the above info.
Before that I want to check how other remote protocols work then according to that I'll send a fix for this and will ask Flavia to review it.
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann edited comment on WFLY-13828 at 9/29/20 7:19 AM:
-------------------------------------------------------------------
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7 over SSL.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol="remote+tls")
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
was (Author: mgrossmann):
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7 over SSL.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol=
http-remoting https-remoting remote remote+http remote+https
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann edited comment on WFLY-13828 at 9/29/20 7:18 AM:
-------------------------------------------------------------------
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7 over SSL.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol=
http-remoting https-remoting remote remote+http remote+https
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
was (Author: mgrossmann):
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol=
http-remoting https-remoting remote remote+http remote+https
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann commented on WFLY-13828:
------------------------------------------
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol=
http-remoting https-remoting remote remote+http remote+https
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFCORE-5113) Formatters defined on handlers via the formatter pattern attribute are not properly removed
by Michal Petrov (Jira)
[ https://issues.redhat.com/browse/WFCORE-5113?page=com.atlassian.jira.plug... ]
Michal Petrov reassigned WFCORE-5113:
-------------------------------------
Assignee: Michal Petrov (was: James Perkins)
> Formatters defined on handlers via the formatter pattern attribute are not properly removed
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-5113
> URL: https://issues.redhat.com/browse/WFCORE-5113
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: Michal Petrov
> Priority: Minor
>
> Most handlers on the logging subsystem have a legacy {{formatter}} attribute which accepts a pattern. When a {{named-formatter}} is not defined this value is used and a {{PatternFormatter}} is created for it's usage. However when the handler is removed the wrong name is checked against the formatter to be removed. This formatter is not used so it doesn't really create any issues, however it should be removed as it's not used.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months