July 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5028) component upgrade to Hibernate ORM 5.0.0.CR4

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-5028?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-5028: ------------------------------- Summary: component upgrade to Hibernate ORM 5.0.0.CR4 (was: component upgrade to Hibernate ORM 5.0.0.CR3) > component upgrade to Hibernate ORM 5.0.0.CR4 > -------------------------------------------- > > Key: WFLY-5028 > URL: https://issues.jboss.org/browse/WFLY-5028 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 10.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-853) Simplify the remote-outbound connections

by Tomasz Adamski (JIRA)

Tomasz Adamski created WFCORE-853: ------------------------------------- Summary: Simplify the remote-outbound connections Key: WFCORE-853 URL: https://issues.jboss.org/browse/WFCORE-853 Project: WildFly Core Issue Type: Feature Request Components: Remoting Affects Versions: 2.0.0.Alpha11 Reporter: Tomasz Adamski Assignee: Tomasz Adamski Create remote-outbound-group element in remoting configuration which gather connections that share the same configuration. http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004235.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-852) add Hibernate Search deployment processor

by Scott Marlow (JIRA)

Scott Marlow created WFCORE-852: ----------------------------------- Summary: add Hibernate Search deployment processor Key: WFCORE-852 URL: https://issues.jboss.org/browse/WFCORE-852 Project: WildFly Core Issue Type: Task Components: Server Reporter: Scott Marlow Assignee: Jason Greene Fix For: 2.0.0.Alpha12 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-852) add Hibernate Search deployment processor

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFCORE-852?page=com.atlassian.jira.plugin... ] Scott Marlow reassigned WFCORE-852: ----------------------------------- Assignee: Scott Marlow (was: Jason Greene) > add Hibernate Search deployment processor > ----------------------------------------- > > Key: WFCORE-852 > URL: https://issues.jboss.org/browse/WFCORE-852 > Project: WildFly Core > Issue Type: Task > Components: Server > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 2.0.0.Alpha12 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5039) Batch JobXmlResolverService should safe copy values from the maps

by James Perkins (JIRA)

James Perkins created WFLY-5039: ----------------------------------- Summary: Batch JobXmlResolverService should safe copy values from the maps Key: WFLY-5039 URL: https://issues.jboss.org/browse/WFLY-5039 Project: WildFly Issue Type: Bug Components: Batch Reporter: James Perkins Assignee: James Perkins {code} 2015-07-30 12:37:31,658 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.subunit."jslxml_ejb_vehicle.ear"."jslxml_ejb_vehicle_client.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."jslxml_ejb_vehicle.ear"."jslxml_ejb_vehicle_client.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "jslxml_ejb_vehicle_client.jar" of deployment "jslxml_ejb_vehicle.ear" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.Alpha11.jar:2.0.0.Alpha11] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] Caused by: java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) [rt.jar:1.8.0_40] at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) [rt.jar:1.8.0_40] at org.wildfly.extension.batch.jberet.deployment.BatchDeploymentResourceProcessor.deploy(BatchDeploymentResourceProcessor.java:60) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.Alpha11.jar:2.0.0.Alpha11] ... 5 more {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1285) rar-info: CCI interface information missing

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1285?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1285: ----------------------------------- Fix Version/s: 1.2.6.Final (was: 1.26) > rar-info: CCI interface information missing > ------------------------------------------- > > Key: JBJCA-1285 > URL: https://issues.jboss.org/browse/JBJCA-1285 > Project: IronJacamar > Issue Type: Bug > Components: AS > Reporter: Jesper Pedersen > Assignee: Johnathon Lee > Fix For: 1.2.6.Final > > > If a resource adapter is using CCI then the ConnectionFactory and Connection information isn't included in the report. > The information should be based directly on the actual interface classes -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1285) rar-info: CCI interface information missing

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-1285: -------------------------------------- Summary: rar-info: CCI interface information missing Key: JBJCA-1285 URL: https://issues.jboss.org/browse/JBJCA-1285 Project: IronJacamar Issue Type: Bug Components: AS Reporter: Jesper Pedersen Assignee: Johnathon Lee Fix For: 1.26 If a resource adapter is using CCI then the ConnectionFactory and Connection information isn't included in the report. The information should be based directly on the actual interface classes -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-809) Copyless stack

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-809?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-809: -------------------------- Attachment: Buf.java BufAllocator.java Added Buf and BufAllocator, will be renamed to Buffer (replacing the Buffer class) > Copyless stack > -------------- > > Key: JGRP-809 > URL: https://issues.jboss.org/browse/JGRP-809 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: Buf.java, BufAllocator.java, Message.java > > > Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can > - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to) > - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return > - each thread in the pool has its own buffer into which the buffer is read from the socket > Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-809) Copyless stack

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-809?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-809: -------------------------- Attachment: Message.java Added setBuffer() / getBuffer() based on Buf > Copyless stack > -------------- > > Key: JGRP-809 > URL: https://issues.jboss.org/browse/JGRP-809 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: Message.java > > > Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can > - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to) > - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return > - each thread in the pool has its own buffer into which the buffer is read from the socket > Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1946) Auth succeeds when the node without auth starts first

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1946?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1946: --------------------------- Fix Version/s: 3.6.5 > Auth succeeds when the node without auth starts first > ----------------------------------------------------- > > Key: JGRP-1946 > URL: https://issues.jboss.org/browse/JGRP-1946 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.4 > Environment: jdk 1.7 > Reporter: fatih fatih > Assignee: Bela Ban > Fix For: 3.6.5 > > Attachments: HAController2.java, udp.xml, udp.xml > > > Node starts without auth it becomes coordinator of its cluster > In the same cluster another node starts with X509 Auth > The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster. > The purpose is not to allow the nodes that is with auth and the nodes that is without auth to join with each other. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 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 2015