[JBoss JIRA] (DROOLS-2436) [DMN Designer] Always open the same diagram
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2436?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2436:
--------------------------------
Description:
User is unable to open two different diagrams.
h2. Acceptance test
# Steps to reproduce fixed (/)
# Steps to reproduce fixed, do the last step in multiple browser sessions (/)
was:
User is unable to open two different diagrams.
h2. Acceptance test
# Steps to reproduce fixed
# Steps to reproduce fixed, do the last step in multiple browser sessions
> [DMN Designer] Always open the same diagram
> -------------------------------------------
>
> Key: DROOLS-2436
> URL: https://issues.jboss.org/browse/DROOLS-2436
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor, Stunner
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Roger Martínez
> Priority: Blocker
>
> User is unable to open two different diagrams.
> h2. Acceptance test
> # Steps to reproduce fixed (/)
> # Steps to reproduce fixed, do the last step in multiple browser sessions (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-5793) Allow selective CI builds
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-5793 at 4/3/18 3:36 AM:
--------------------------------------------------------------
The update to this is that we now manage documentation within the wildfly repo in master branch, so any updates to the docs here do not need to run the whole CI -- probably only some sort of 'doc lint'. So the time saving cost here is *huge*.
Though, PRs that are also changing code but in subsequent updates only update documentation, the CI can't tell those apart and will have to run the whole suite again -- this is a disadvantage to having documentation as part of project source repo.
was (Author: rhusar):
The update to this is that we now manage documentation within the wildfly repo in master branch, so any updates to the docs here do not need to run the whole CI -- problably only some sort of 'doc lint'. Though, PRs that are also changing code but in subsequent updates only update documentation, the CI can't tell those apart and will have to run the whole suite again -- this is a disadvantage to having documentation as part of project source repo.
> Allow selective CI builds
> -------------------------
>
> Key: WFLY-5793
> URL: https://issues.jboss.org/browse/WFLY-5793
> Project: WildFly
> Issue Type: Task
> Reporter: Ryan Emerson
> Assignee: Ken Wills
> Priority: Optional
>
> Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md).
> A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-5793) Allow selective CI builds
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-5793 at 4/3/18 3:36 AM:
--------------------------------------------------------------
The update to this is that we now manage documentation within the wildfly repo in master branch, so any updates to the docs here do not need to run the whole CI -- probably only some sort of 'doc lint'. So the machine time saving cost here is huge.
Though, PRs that are also changing code but in subsequent updates only update documentation, the CI can't tell those apart and will have to run the whole suite again -- this is a disadvantage to having documentation as part of project source repo.
was (Author: rhusar):
The update to this is that we now manage documentation within the wildfly repo in master branch, so any updates to the docs here do not need to run the whole CI -- probably only some sort of 'doc lint'. So the time saving cost here is *huge*.
Though, PRs that are also changing code but in subsequent updates only update documentation, the CI can't tell those apart and will have to run the whole suite again -- this is a disadvantage to having documentation as part of project source repo.
> Allow selective CI builds
> -------------------------
>
> Key: WFLY-5793
> URL: https://issues.jboss.org/browse/WFLY-5793
> Project: WildFly
> Issue Type: Task
> Reporter: Ryan Emerson
> Assignee: Ken Wills
> Priority: Optional
>
> Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md).
> A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-5793) Allow selective CI builds
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5793:
--------------------------------------
The update to this is that we now manage documentation within the wildfly repo in master branch, so any updates to the docs here do not need to run the whole CI -- problably only some sort of 'doc lint'. Though, PRs that are also changing code but in subsequent updates only update documentation, the CI can't tell those apart and will have to run the whole suite again -- this is a disadvantage to having documentation as part of project source repo.
> Allow selective CI builds
> -------------------------
>
> Key: WFLY-5793
> URL: https://issues.jboss.org/browse/WFLY-5793
> Project: WildFly
> Issue Type: Task
> Reporter: Ryan Emerson
> Assignee: Ken Wills
> Priority: Optional
>
> Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md).
> A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-5793) Allow selective CI builds
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5793:
---------------------------------
Issue Type: Task (was: Enhancement)
> Allow selective CI builds
> -------------------------
>
> Key: WFLY-5793
> URL: https://issues.jboss.org/browse/WFLY-5793
> Project: WildFly
> Issue Type: Task
> Reporter: Ryan Emerson
> Assignee: Ken Wills
> Priority: Optional
>
> Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md).
> A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2436) [DMN Designer] Always open the same diagram
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2436?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2436:
--------------------------------
Description:
User is unable to open two different diagrams.
h2. Acceptance test
# Steps to reproduce fixed
# Steps to reproduce fixed, do the last step in multiple browser sessions
was:User is unable to open two different diagrams.
> [DMN Designer] Always open the same diagram
> -------------------------------------------
>
> Key: DROOLS-2436
> URL: https://issues.jboss.org/browse/DROOLS-2436
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor, Stunner
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Roger Martínez
> Priority: Blocker
>
> User is unable to open two different diagrams.
> h2. Acceptance test
> # Steps to reproduce fixed
> # Steps to reproduce fixed, do the last step in multiple browser sessions
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10143) Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10143?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-10143:
---------------------------------------
[~jmesnil] This issue is in Wildfly 12.0.0.Final. Reproducing is simple. Just lookup RemoteConnectionFactory and use only jboss-client.jar from @JBOSS_HOME/bin/client/jboss-client.jar:
{code}
final Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
env.put(Context.PROVIDER_URL, "http-remoting://" + hostname + ":" + 8080);
Context context = new InitialContext(env);
ConnectionFactory cf = (ConnectionFactory) context.lookup("jms/RemoteConnectionFactory");
{code}
> Standalone JMS client is failing with: java.lang.ClassNotFoundException: javax.json.JsonValue with jboss-client.jar
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10143
> URL: https://issues.jboss.org/browse/WFLY-10143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> If standalone JMS client is using only jboss-client.jar on classpath then during look up of connection factory fails with:
> {code}
> Exception in thread "Thread-0" java.lang.NoClassDefFoundError: javax/json/JsonValue
> at org.apache.activemq.artemis.uri.schema.connector.TCPTransportConfigurationSchema.getTransportConfigurations(TCPTransportConfigurationSchema.java:68)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:44)
> at org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:33)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:86)
> at org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:30)
> at org.apache.activemq.artemis.utils.uri.URIFactory.newObject(URIFactory.java:59)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.newLocator(ServerLocatorImpl.java:411)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:209)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:202)
> at org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory.<init>(ActiveMQJMSConnectionFactory.java:34)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at org.jboss.marshalling.reflect.SerializableClass.invokeConstructor(SerializableClass.java:340)
> at org.jboss.marshalling.reflect.SerializableClass.callNoArgConstructor(SerializableClass.java:292)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1408)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:205)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:243)
> at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:190)
> at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
> at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
> at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.store.RelativeFederatingContext.lookupNative(RelativeFederatingContext.java:58)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
> at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:66)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.jms.client.ProducerTransAck.run(ProducerTransAck.java:78)
> Caused by: java.lang.ClassNotFoundException: javax.json.JsonValue
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 33 more
> {code}
> This is because javax.json-api jar is missing.
> Wildfly 12 jms-client-bom does not suffer by this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months