[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-471 at 5/2/14 9:34 AM:
-----------------------------------------------------------------
Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar. For example, you can't deploy a war that contains weld to JBoss EAP, because EAP already has weld and it doesn't accept wars that include it too.
Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:
- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.
But if an issue does slip through and wasn't detected, don't blame the guy trying to improve our deps, blame the lack of arq tests.
was (Author: ge0ffrey):
Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar.
Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:
- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.
But if an issue does slip through and wasn't detected, don't blame the guy trying to improve our deps, blame the lack of arq tests.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-471 at 5/2/14 9:32 AM:
-----------------------------------------------------------------
Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar.
Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:
- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.
But if an issue does slip through and wasn't detected, don't blame the guy trying to improve our deps, blame the lack of arq tests.
was (Author: ge0ffrey):
Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar.
Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:
- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.
But if an issue does slip through, don't blame the guy trying to improve our deps, blame the lack of arq tests.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-471:
-----------------------------------------
Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar.
Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:
- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.
But if an issue does slip through, don't blame the guy trying to improve our deps, blame the lack of arq tests.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-471 at 5/2/14 9:32 AM:
-----------------------------------------------------------------
Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar.
Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:
- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.
But if an issue does slip through, don't blame the guy trying to improve our deps, blame the lack of arq tests.
was (Author: ge0ffrey):
Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar.
Note: those assembly xml's are the recipe to build the wars/zips.
Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something.
That doesn't mean we should stop improving our dependencies and or build :)
It just means there's a known risk and we should do a best effort when changing them:
- Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files.
But if an issue does slip through, don't blame the guy trying to improve our deps, blame the lack of arq tests.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (JGRP-1833) Add JAAS support to the SASL protocol
by Tristan Tarrant (JIRA)
Tristan Tarrant created JGRP-1833:
-------------------------------------
Summary: Add JAAS support to the SASL protocol
Key: JGRP-1833
URL: https://issues.jboss.org/browse/JGRP-1833
Project: JGroups
Issue Type: Feature Request
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 3.5
Add configuration options so that the SASL protocol can be given a client/server Subject or a JAAS LoginModule so that it can create the SaslClient/SaslServer with the correct security environment (required by GSSAPI).
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBWEB-297:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1090103, https://bugzilla.redhat.com/show_bug.cgi?id=1093718 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1090103)
> NIO can improperly lead to request/response objects being used concurrently
> ---------------------------------------------------------------------------
>
> Key: JBWEB-297
> URL: https://issues.jboss.org/browse/JBWEB-297
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: JBWEB-297.diff
>
>
> Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event():
> {code:title=Http11NioProtocol.java|borderStyle=solid}
> public SocketState event(NioChannel channel, SocketStatus status) {
> Http11NioProcessor processor = connections.get(channel.getId());
> SocketState state = SocketState.CLOSED;
> if (processor != null) {
> processor.startProcessing();
> // Call the appropriate event
> try {
> state = processor.event(status);
> } catch (java.net.SocketException e) {
> // SocketExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> } catch (java.io.IOException e) {
> // IOExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> }
> // Future developers: if you discover any other
> // rare-but-nonfatal exceptions, catch them here, and log as
> // above.
> catch (Throwable e) {
> // any other exception or error is odd. Here we log it
> // with "ERROR" level, so it will show up even on
> // less-than-verbose logs.
> CoyoteLogger.HTTP_NIO_LOGGER.socketError(e);
> } finally {
> if (state != SocketState.LONG) {
> connections.remove(channel.getId());
> recycledProcessors.offer(processor);
> {code}
> If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors.
> It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run().
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-3311) Intermittent connection TimeOut with CLI using https-remoting
by Filip Bogyai (JIRA)
Filip Bogyai created WFLY-3311:
----------------------------------
Summary: Intermittent connection TimeOut with CLI using https-remoting
Key: WFLY-3311
URL: https://issues.jboss.org/browse/WFLY-3311
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 8.1.0.CR1
Reporter: Filip Bogyai
Assignee: Alexey Loubyansky
When the management http-interface is secured to use https and the CLI is using https-remoting to connect, sometimes it hangs which leads to connection timeout. This occurs approximately in 1 out of 10 times if you try to connect with CLI in a short time.
{code}
org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.modules.Module.run(Module.java:312)
at org.jboss.modules.Main.main(Main.java:460)
Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9993
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:840)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:819)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276)
... 8 more
Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1005)
... 11 more
Caused by: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
... 13 more
{code}
This problem also causes intermittent test failures in testsuite, for example:
http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI...
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer commented on DROOLS-471:
-----------------------------------------------
having build problems when removing dependencies in kie-wb-distributions/kie-eap-integration/kie-eap-modules/kie-jboss-eap-base-modules/jboss-eap-6.1.1/javax-security-jacc-api-main/pom.xml.
Try to sort this out.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months