September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3806) org.jboss.metadata main needs to be restored

by Stan Silvert (JIRA)

Stan Silvert created WFLY-3806: ---------------------------------- Summary: org.jboss.metadata main needs to be restored Key: WFLY-3806 URL: https://issues.jboss.org/browse/WFLY-3806 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 9.0.0.Beta1 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 9.0.0.Beta1 The org.jboss.metadata main module has gone away in WildFly 9. This used to include all the jboss metadata resources but has now been broken up. However, this breaks the Keycloak subsystem and any other module that used to reference it as a dependency. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2011?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2011: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1004856|https://bugzilla.redhat.com/show_bug.cgi?id=1004856] from ASSIGNED to POST > jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element > ------------------------------------------------------------------------------------- > > Key: WFLY-2011 > URL: https://issues.jboss.org/browse/WFLY-2011 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Beta1 > Reporter: Wolf-Dieter Fink > Assignee: Stuart Douglas > Labels: ejb-jar.xml > Fix For: 8.0.0.CR1 > > > If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent. > From the XSD the <ejb-name> element can not be added multiple times. > And the following configuration will be not valid: > <assembly-descriptor> > <c:clustering> > <ejb-name>Bean1</ejb-name> > <ejb-name>Bean2</ejb-name> > <c:clustered>true</c:clustered> > </c:clustering> > </assembly-descriptor> > The parser should throw an Exception and the application should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strage number and content of subgroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1876: -------------------------------- Take a look at {{Merger.sanitizeViews()}}, which might generate these weird sub-views. > MERGE3 : Strage number and content of subgroups > ----------------------------------------------- > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.6 > > Attachments: DkeJgrpAddress.java, MergeViewWith210Subgroups.log > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: > {code} > {A, B, C} => {A, B, C} and {C} => {A, B, C} > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strage number and content of subgroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1876: --------------------------- Attachment: DkeJgrpAddress.java Custom address code attached > MERGE3 : Strage number and content of subgroups > ----------------------------------------------- > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.6 > > Attachments: DkeJgrpAddress.java, MergeViewWith210Subgroups.log > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: > {code} > {A, B, C} => {A, B, C} and {C} => {A, B, C} > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1877) System.nanoTime() may be negative

by Bela Ban (JIRA)

Bela Ban created JGRP-1877: ------------------------------ Summary: System.nanoTime() may be negative Key: JGRP-1877 URL: https://issues.jboss.org/browse/JGRP-1877 Project: JGroups Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.5.1, 3.6 According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a negative value. Code like the one below might fail: {code:title=Responses.waitFor()|borderStyle=solid} public boolean waitFor(long timeout) { long wait_time; final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns lock.lock(); try { while(!done && (wait_time=target_time - System.nanoTime()) > 0) { try { cond.await(wait_time,TimeUnit.NANOSECONDS); } catch(InterruptedException e) { } } return done; } finally { lock.unlock(); } } {code} Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a negative value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-905) Arquillian/Remote support

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-905?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-905. --------------------------------- Resolution: Won't Fix > Arquillian/Remote support > ------------------------- > > Key: JBJCA-905 > URL: https://issues.jboss.org/browse/JBJCA-905 > Project: IronJacamar > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Arquillian > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1109) SimpleResourceAdapterRepository fails to convert RA uniqueId to RA name

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1109?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1109. ---------------------------------- Resolution: Deferred > SimpleResourceAdapterRepository fails to convert RA uniqueId to RA name > ----------------------------------------------------------------------- > > Key: JBJCA-1109 > URL: https://issues.jboss.org/browse/JBJCA-1109 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 1.0.21.Final, 1.1.1.Final > Reporter: Ivo Studensky > Assignee: Jesper Pedersen > > SimpleResourceAdapterRepository compares a given ResourceAdapter class with resource adapters from MetadataRepository just by their class names. So if there are 2 separate RAs deployed in the server both with the same ResourceAdapter class (e.g. org.hornetq.ra.HornetQResourceAdapter), it randomly takes one of those and cannot safely distinguish them. > 3 places affected by this: > 1. #getMessageListeners() [1] > 2. #getEnpoint() because of usage of getMDRIdentifier [2] [3] > 3. #getResourceAdapters() [4] > I used a dirty hack to work around this issue which changes API and doesn't fix #3, see [5] + a few changes according to [5] in WF's EJBUtilities. > A possible fix could be to "encode" the RA name into its {{uniqueId}}, so that such a uniqueId would contain RA class name, RA name and eventually a counter (increasing number). > [1] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/or... > [2] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/or... > [3] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/or... > [4] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/or... > [5] https://github.com/istudens/ironjacamar/commit/0f716538ea91e2b547f83f41c6... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-233) Support for non file protocol URL deployments

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-233?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-233. --------------------------------- Resolution: Won't Fix > Support for non file protocol URL deployments > --------------------------------------------- > > Key: JBJCA-233 > URL: https://issues.jboss.org/browse/JBJCA-233 > Project: IronJacamar > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Deployer > Reporter: Aslak Knutsen > Assignee: Jesper Pedersen > Priority: Minor > Attachments: JBJCA-233-Shrinkwrap.patch, JBJCA-233.patch > > > Deployer.deploy(URL) should fully support URL as a deployment unit, not only file:// URLs. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-657) Support javax.sql.XADataSource as connection factory

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-657?page=com.atlassian.jira.plugin.... ] Jesper Pedersen closed JBJCA-657. --------------------------------- Resolution: Won't Fix > Support javax.sql.XADataSource as connection factory > ---------------------------------------------------- > > Key: JBJCA-657 > URL: https://issues.jboss.org/browse/JBJCA-657 > Project: IronJacamar > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JDBC > Reporter: Jim Crossley > Assignee: Jesper Pedersen > > For <xa-datasource> definitions, the "wrapper" object returned from JNDI does not implement XADataSource -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-77) Verify OSGi information in all manifests

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-77?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen updated JBJCA-77: --------------------------------- Fix Version/s: (was: 2.0.0.CR1) Priority: Major (was: Blocker) Assignee: (was: Jesper Pedersen) > Verify OSGi information in all manifests > ---------------------------------------- > > Key: JBJCA-77 > URL: https://issues.jboss.org/browse/JBJCA-77 > Project: IronJacamar > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Common, Core, Deployer > Reporter: Jesper Pedersen > > Verify that the OSGi information in all the MANIFEST.MF files are correct. > This information needs to be kept in sync from this point on. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014