July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-1563. -------------------------------------- Fix Version/s: (was: 2.2.0.CR2) Resolution: Done > Failed CLI batch command with "deploy --force" for replace deployment > --------------------------------------------------------------------- > > Key: WFCORE-1563 > URL: https://issues.jboss.org/browse/WFCORE-1563 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.1.0.Final, 3.0.0.Alpha1 > Reporter: ted won > Assignee: ted won > Priority: Minor > Labels: cli, jboss > Fix For: 3.0.0.Alpha2 > > Attachments: jboss-ejb-in-ear.ear > > > Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part." > {code:title=Command} > jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli" > {code} > {code:title=deploy.cli} > batch > deploy --force ./jboss-ejb-in-ear.ear > run-batch > {code} > {panel:title=Full Error message} > Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part. > or > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part. > {panel} > {panel:title=Expected message} > The batch executed successfully > {panel} > However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error. > There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below. > Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle() > ------------------------------------------------------------------------------------------- > * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd() > {code} > { > "operation" => "add", > "address" => {"deployment" => "jboss-ejb-in-ear.ear"}, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- > * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace() > {code} > { > "operation" => "full-replace-deployment", > "name" => "jboss-ejb-in-ear.ear", > "enabled" => true, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- > * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace() > {code} > { > "operation" => "full-replace-deployment", > "name" => "jboss-ejb-in-ear.ear", > "address" => [], > "enabled" => true, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ] Brian Stansberry reopened WFCORE-1563: -------------------------------------- Reopening to correct Fix Version. > Failed CLI batch command with "deploy --force" for replace deployment > --------------------------------------------------------------------- > > Key: WFCORE-1563 > URL: https://issues.jboss.org/browse/WFCORE-1563 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.1.0.Final, 3.0.0.Alpha1 > Reporter: ted won > Assignee: ted won > Priority: Minor > Labels: cli, jboss > Fix For: 2.2.0.CR2, 3.0.0.Alpha2 > > Attachments: jboss-ejb-in-ear.ear > > > Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part." > {code:title=Command} > jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli" > {code} > {code:title=deploy.cli} > batch > deploy --force ./jboss-ejb-in-ear.ear > run-batch > {code} > {panel:title=Full Error message} > Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part. > or > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part. > {panel} > {panel:title=Expected message} > The batch executed successfully > {panel} > However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error. > There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below. > Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle() > ------------------------------------------------------------------------------------------- > * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd() > {code} > { > "operation" => "add", > "address" => {"deployment" => "jboss-ejb-in-ear.ear"}, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- > * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace() > {code} > { > "operation" => "full-replace-deployment", > "name" => "jboss-ejb-in-ear.ear", > "enabled" => true, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- > * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace() > {code} > { > "operation" => "full-replace-deployment", > "name" => "jboss-ejb-in-ear.ear", > "address" => [], > "enabled" => true, > "content" => [{"bytes" => bytes { > ... > }}] > } > {code} > ------------------------------------------------------------------------------------------- -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2800) Re-invoking InterceptorContext.proceed() throws CannotProceedException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2800?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2800: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1360851 Bugzilla Update: Perform > Re-invoking InterceptorContext.proceed() throws CannotProceedException > ---------------------------------------------------------------------- > > Key: WFLY-2800 > URL: https://issues.jboss.org/browse/WFLY-2800 > Project: WildFly > Issue Type: Bug > Reporter: Eric van der Maarel > Assignee: David Lloyd > Fix For: 8.0.0.Final > > > When you invoke and re-invoke org.jboss.invocation.InterceptorContext.proceed() from an interceptor in a chain of interceptors and the interceptor to be (re-)invoked is a org.jboss.invocation.ChainedInterceptor or WeavedInterceptor, a CannotProceedException is thrown. > This bug has been described and analysed in the context of the ejb3 container, on the forum at https://community.jboss.org/message/853547. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1665) Enable gc logging function in startup scripts; require env var to enable it

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1665?page=com.atlassian.jira.plugi... ] Tomaz Cerar updated WFCORE-1665: -------------------------------- Summary: Enable gc logging function in startup scripts; require env var to enable it (was: Uncomment gc logging function in startup scripts; require env var to enable it) > Enable gc logging function in startup scripts; require env var to enable it > --------------------------------------------------------------------------- > > Key: WFCORE-1665 > URL: https://issues.jboss.org/browse/WFCORE-1665 > Project: WildFly Core > Issue Type: Task > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha4 > > > Our startup scripts have gc logging functionality specified by EAP6-121 that is commented out by default. > This approach to disabling this function makes it difficult to use these scripts in EAP; see JBEAP-5374. > We should uncomment function this but only enable it if an env var is set. The .conf files core ships will not set this env var. The ones EAP ships can. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2093) Remove Externalizable from Address

by Bela Ban (JIRA)

Bela Ban created JGRP-2093: ------------------------------ Summary: Remove Externalizable from Address Key: JGRP-2093 URL: https://issues.jboss.org/browse/JGRP-2093 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.0 This allows us to remove {{writeExternal()}} and {{readExternal()}} from all addresses, plus {{serialVersionUUID}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6512) Missing explanation which services failed to start

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6512?page=com.atlassian.jira.plugin.... ] Radoslav Husar closed WFLY-6512. -------------------------------- Resolution: Duplicate Duplicates WFLY-5688. > Missing explanation which services failed to start > -------------------------------------------------- > > Key: WFLY-6512 > URL: https://issues.jboss.org/browse/WFLY-6512 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 10.0.0.Final > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > > Missing info which services failed to start on server startup > E.g. when I change in mod_cluster subsystem connector reference to invalid one (/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=connector, value=invalid), the server fails to start several services without explaining which ones. This is user unfriendly as it creates hard effort to find out what is actually wrong. There should be at least pointed out which services failed to start. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1228) Entry point update halts the rule Engine

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1228?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1228. ------------------------------- Resolution: Cannot Reproduce Bug I tried to reproduce what you described with the test case I'm pasting below, but it works for me. If you're still having this issue please create a complete reproducer (maybe reusing part of what I did) attach it to this ticket and reopen the ticket. {code} @Test public void testUpdateDuringFireUntilHalt() throws Exception { String drl = "import " + AtomicInteger.class.getCanonicalName() + ";\n" + "import " + BlockingQueue.class.getCanonicalName() + ";\n" + "global BlockingQueue queue;\n" + "rule R1 when\n" + " $i: Integer(this > 0) \n" + "then " + " delete($i);" + "end\n" + "rule R2 when\n" + " $i: AtomicInteger(get() == 0 || get() == 2) \n" + "then " + " modify($i) { set( $i.get() + 1 ) };" + " queue.put($i);" + "end\n"; final KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL ) .build() .newKieSession(); BlockingQueue<AtomicInteger> queue = new LinkedBlockingQueue<AtomicInteger>(); ksession.setGlobal("queue", queue); new Thread () { public void run () { ksession.fireUntilHalt(); } }.start(); new Thread () { public void run () { // keep the engine busy for (int i = 1; i < 1000000; i++) { ksession.insert( i ); } } }.start(); AtomicInteger obj = new AtomicInteger(0); FactHandle fh = ksession.insert( obj ); for (int i = 0; i < 2; i++) { AtomicInteger aInt = queue.take(); if (aInt.get() % 2 == 0) { fail(aInt + " should be odd"); } aInt.set(aInt.get()+1); ksession.update( fh, aInt ); } ksession.halt(); assertEquals( 4, obj.get() ); } {code} > Entry point update halts the rule Engine > ---------------------------------------- > > Key: DROOLS-1228 > URL: https://issues.jboss.org/browse/DROOLS-1228 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: Linux, JBOSS 6.3 EAP, Java 8, Drools 6.2 > Reporter: mithun singh > Assignee: Mario Fusco > Priority: Blocker > Attachments: structure.png > > > 1. A Stateful session is created. > 2. Facts are loaded to stateful session and after successful loading into session we initiate "*fireUntilHault()*" inorder to fire the rules, where we have about 38 rules. > 3. We have configured a queue inorder to receive messages from source system and load the relevant facts into the session by retrieving the entry point from the session, update the fact and set focus to the relevant agenda group. > 4. We are not able to update the fact using *"EntryPoint.update(Fact)"*. We could see that this occurs if the rule Engine starts firing facts and we subsequently update the fact in the session. > 5. According to drools, rule engine will handle the sequence of updates and firing of rules accordingly. > 6. But rule engine comes to halt state and there is no exception related to this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2080: -------------------------------- There's a problem with {{AddressGenerator}} in {{JChannel}}: if more than one is installed, the returned address needs to be {{ExtendedUUID}}! This requires more investigation... > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-605) Add an allowAllSaslMechanisms option

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-605: ------------------------------------ Summary: Add an allowAllSaslMechanisms option Key: ELY-605 URL: https://issues.jboss.org/browse/ELY-605 Project: WildFly Elytron Issue Type: Feature Request Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta7 This way we can add all and just filter the mechanisms we want to exclude in the configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1594) CLI to support attached file streams

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1594?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1594: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1698 > CLI to support attached file streams > ------------------------------------ > > Key: WFCORE-1594 > URL: https://issues.jboss.org/browse/WFCORE-1594 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > This entry tracks the addition of a support for attached files in CLI operations, > Operation arguments of type INT and annotated with *attached-stream* and *filesystem-path* must be attached to the Operation. > Users will not deal directly with streams, but with file paths. > The CLI must discover such arguments and: > 1) Propose completion by looking up the file system > 2) Replace the path by a stream index > 3) Send the File streams as attachements > This must be supported both in batch and non batch mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016