March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3177) wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3177?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-3177: ------------------------------------ In the wildfly/modules/system/layers/base/org/eclipse/persistence/main folder is the jipijapa-eclipselink-1.0.1.Final.jar file. Contents of jipijapa-eclipselink-1.0.1.Final.jar are: {quote} META-INF/ META-INF/MANIFEST.MF org/ org/jipijapa/ org/jipijapa/eclipselink/ META-INF/services/ org/jipijapa/eclipselink/JBossAS7ServerPlatform.class org/jipijapa/eclipselink/VFSArchive.class org/jipijapa/eclipselink/VFSArchive$1.class org/jipijapa/eclipselink/JBossAS7ServerPlatform$JBossAS7TransactionController.class org/jipijapa/eclipselink/EclipseLinkPersistenceProviderAdaptor.class org/jipijapa/eclipselink/JBossArchiveFactoryImpl.class org/jipijapa/eclipselink/JBossLogger.class META-INF/services/org.jipijapa.plugin.spi.PersistenceProviderAdaptor META-INF/maven/ META-INF/maven/org.jipijapa/ META-INF/maven/org.jipijapa/jipijapa-eclipselink/ META-INF/maven/org.jipijapa/jipijapa-eclipselink/pom.xml META-INF/maven/org.jipijapa/jipijapa-eclipselink/pom.properties {quote} In [https://github.com/jipijapa/jipijapa/blob/master/eclipselink/src/main/jav...], the "eclipselink.logging.logger" property should be set to org.jipijapa.eclipselink.JBossLogger which looks right to me. What are your persistence.xml contents? > wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly. > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3177 > URL: https://issues.jboss.org/browse/WFLY-3177 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Reporter: Ravshan Samandarov > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3177) wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3177?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-3177: ------------------------------- Component/s: JPA / Hibernate > wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly. > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3177 > URL: https://issues.jboss.org/browse/WFLY-3177 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Reporter: Ravshan Samandarov > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3184) Accept non-list params for deployment add command's 'content' param

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-3184: -------------------------------------- Summary: Accept non-list params for deployment add command's 'content' param Key: WFLY-3184 URL: https://issues.jboss.org/browse/WFLY-3184 Project: WildFly Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor The deployment resource's 'content' attribute is of type list, but it only accepts a single element. Changing this would break compatibility, but it would be nice if CLI users could skip the useless []. This could be handled server-side using a ParameterCorrector, but we'd need to figure out how to prevent validation problems when the user tries it in the CLI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3182) Upgrade to JBoss Negotiation 2.3.0.CR1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3182?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3182: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1081607|https://bugzilla.redhat.com/show_bug.cgi?id=1081607] from ASSIGNED to POST > Upgrade to JBoss Negotiation 2.3.0.CR1 > -------------------------------------- > > Key: WFLY-3182 > URL: https://issues.jboss.org/browse/WFLY-3182 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-812) Release JBoss Negotiation 2.3.0.CR1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-812?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-812: -------------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1081607|https://bugzilla.redhat.com/show_bug.cgi?id=1081607] from ASSIGNED to POST > Release JBoss Negotiation 2.3.0.CR1 > ----------------------------------- > > Key: SECURITY-812 > URL: https://issues.jboss.org/browse/SECURITY-812 > Project: PicketBox > Issue Type: Release > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_0_CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1070) Add a redirect-socket configuration to the web connector config

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1070?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1070: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 900786|https://bugzilla.redhat.com/show_bug.cgi?id=900786] from POST to MODIFIED > Add a redirect-socket configuration to the web connector config > --------------------------------------------------------------- > > Key: WFLY-1070 > URL: https://issues.jboss.org/browse/WFLY-1070 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 8.0.0.CR1 > > > Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group. > The referenced forum thread has an example that uses "redirect-port" for this, but a new attribute would be needed, since changing the meaning of "redirect-port" would be incompatible. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-939) Class-Path manifest entries for WARs-in-EAR not handled properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-939: ---------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 955818|https://bugzilla.redhat.com/show_bug.cgi?id=955818] from POST to MODIFIED > Class-Path manifest entries for WARs-in-EAR not handled properly > ---------------------------------------------------------------- > > Key: WFLY-939 > URL: https://issues.jboss.org/browse/WFLY-939 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha1 > > > ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken. > https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml > The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader. > When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR. > When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run. > I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3081) Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3081?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3081: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 900786|https://bugzilla.redhat.com/show_bug.cgi?id=900786] from POST to MODIFIED > Redirect Forward port web subsystem1.6 xsd and parser from EAP 6.3 > ------------------------------------------------------------------ > > Key: WFLY-3081 > URL: https://issues.jboss.org/browse/WFLY-3081 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web (JBoss Web) > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group. > Support for configuring proxy port and proxy name using socket-binding also. > + add transformers -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3046: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1038993|https://bugzilla.redhat.com/show_bug.cgi?id=1038993] from POST to MODIFIED > Not possible change the object store type from hornetq to jdbc via cli commands > ------------------------------------------------------------------------------- > > Key: WFLY-3046 > URL: https://issues.jboss.org/browse/WFLY-3046 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Final > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.0.1.Final > > > When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file. > How to reproduce: > # ./bin/standalone.xml (start eap 6.2.0.GA) > # ./bin/jboss-cli.sh -c (connect to running eap) > # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true) > # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload > # /subsystem=transactions/log-store=log-store:read-attribute(name=type) > The object store stays to be set to hornetq and no change happens in the standalone.xml file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover for corruption issue

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1813: -------------------------------- Assuming you don't want to purge the table manually, the best option I see here is to remove the offending row(s) from the table when encountering an exception. > JDBC_PING fails to recover for corruption issue > ----------------------------------------------- > > Key: JGRP-1813 > URL: https://issues.jboss.org/browse/JGRP-1813 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Environment: Windows 7 > Reporter: Brett Donahue > Assignee: Bela Ban > Priority: Minor > Labels: EOFException, JDBC_PING,, corruption > Fix For: 3.5 > > > heap space was exhausted and issues occurred. In the end, one node in the cluster must have corrupted the data in the JDBC_PING table. From this point onward, our log is full of these (every two seconds): > 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null > at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340) > at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226) > at org.jgroups.util.Util.readAddress(Util.java:929) > at org.jgroups.util.Util.readAddresses(Util.java:1047) > at org.jgroups.protocols.PingData.readFrom(PingData.java:163) > at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753) > at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625) > at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221) > at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201) > at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68) > at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263) > at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227) > at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208) > at org.jgroups.protocols.Discovery.down(Discovery.java:551) > at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101) > at org.jgroups.protocols.MERGE2.down(MERGE2.java:185) > at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363) > at org.jgroups.protocols.FD.down(FD.java:307) > at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84) > at org.jgroups.protocols.BARRIER.down(BARRIER.java:95) > at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533) > at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575) > at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) > at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925) > at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201) > at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75) > at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40) > at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052) > at org.jgroups.protocols.FlowControl.down(FlowControl.java:340) > at org.jgroups.protocols.FRAG2.down(FRAG2.java:136) > at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237) > at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024) > at org.jgroups.JChannel.down(JChannel.java:760) > at org.jgroups.JChannel._connect(JChannel.java:538) > at org.jgroups.JChannel.connect(JChannel.java:290) > at org.jgroups.JChannel.connect(JChannel.java:275) > at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45) > at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59) > at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187) > at java.lang.Thread.run(Thread.java:791) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 1 month

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 March 2014