[JBoss JIRA] Created: (JBXB-109) Element type causes parse error
by Scott M Stark (JIRA)
Element type causes parse error
-------------------------------
Key: JBXB-109
URL: http://jira.jboss.com/jira/browse/JBXB-109
Project: JBoss XML Binding (JBossXB)
Issue Type: Bug
Affects Versions: JBossXB-2.0.0.CR5
Reporter: Scott M Stark
Assigned To: Adrian Brock
Fix For: JBossXB-2.0.0.CR5
If I uncomment the proxyFactoryConfig property on the InvokerProxyBindingMetaData bean, the JBoss5xEverything.testEverything test starts to fail with a CCE:
org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/home/svn/Common/trunks/jbossxb/target/test-classes/org/jboss/test/ejb/metadata/test/JBoss5xEverything_testEverything.xml@2693,38
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:184)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
at org.jboss.test.xb.builder.JBossXBTestDelegate.unmarshal(JBossXBTestDelegate.java:121)
at org.jboss.test.javaee.metadata.AbstractJavaEEMetaDataTest.unmarshal(AbstractJavaEEMetaDataTest.java:184)
at org.jboss.test.javaee.metadata.AbstractJavaEEMetaDataTest.unmarshal(AbstractJavaEEMetaDataTest.java:154)
at org.jboss.test.javaee.metadata.AbstractJavaEEMetaDataTest.unmarshal(AbstractJavaEEMetaDataTest.java:120)
at org.jboss.test.ejb.metadata.test.JBoss5xEverythingUnitTestCase.unmarshal(JBoss5xEverythingUnitTestCase.java:106)
at org.jboss.test.ejb.metadata.test.JBoss5xEverythingUnitTestCase.testEverything(JBoss5xEverythingUnitTestCase.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.lang.RuntimeException: QName {http://java.sun.com/xml/ns/javaee}description error adding java.util.ArrayList@16e1eea8 to collection org.jboss.javaee.metadata.spec.DescriptionsImpl@4afb6354
at org.jboss.xb.builder.runtime.CollectionPropertyHandler.handle(CollectionPropertyHandler.java:137)
at org.jboss.xb.builder.runtime.AbstractPropertyHandler.doHandle(AbstractPropertyHandler.java:98)
at org.jboss.xb.builder.runtime.PropertyWildcardHandler.setParent(PropertyWildcardHandler.java:72)
at org.jboss.xb.binding.group.ValueListHandler$FACTORY$1.newInstance(ValueListHandler.java:401)
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endRepeatableParticle(SundayContentHandler.java:825)
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:319)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:402)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:180)
... 23 more
Caused by: java.lang.ClassCastException: java.util.ArrayList
at org.jboss.javaee.metadata.support.MappedAnnotationMetaData.add(MappedAnnotationMetaData.java:1)
at org.jboss.xb.builder.runtime.CollectionPropertyHandler.handle(CollectionPropertyHandler.java:133)
... 40 more
The JBoss5xEverything_testEverything.xml was updated to include a proxy-factory-config element, but this is not being reached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JGRP-627) Enabling JMX when using multiplexer.
by Robert Newson (JIRA)
Enabling JMX when using multiplexer.
------------------------------------
Key: JGRP-627
URL: http://jira.jboss.com/jira/browse/JGRP-627
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6
Reporter: Robert Newson
Assigned To: Bela Ban
While debugging other issues (the disparity between cluster views and service views), I attempted to add JMX support. However, having looked at the code, it turns out that ObjectNames are formed incorrectly.
Caused by: javax.management.MalformedObjectNameException: Invalid character ':' in value part of property
at javax.management.ObjectName.construct(ObjectName.java:602)
at javax.management.ObjectName.<init>(ObjectName.java:1394)
at org.jgroups.jmx.JmxConfigurator.registerChannel(JmxConfigurator.java:55)
at org.jgroups.jmx.JmxConfigurator.registerChannel(JmxConfigurator.java:41)
at org.jgroups.JChannelFactory.registerChannel(JChannelFactory.java:383)
at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:297)
at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:280)
It's attempting an ObjectName of the form "jgroups:name=Multiplexer:type=channel,cluster=blah" which is illegal.
I enabled JMX by calling;
channelFactory.setExposeChannels(true);
channelFactory.create();
Am I doing this wrong or does the JMX registration simply not work?
I can work around this with;
channelFactory.setDomain("jgroups")
but this doesn't group the JMX beans in the way the code intends.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JGRP-620) RpcDispatcher.callRemoteMethods() hangs
by P Eger (JIRA)
RpcDispatcher.callRemoteMethods() hangs
---------------------------------------
Key: JGRP-620
URL: http://jira.jboss.com/jira/browse/JGRP-620
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5.1
Environment: RHEL4 64 bit: Linux svr5 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:13:42 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
SUN JDK 1.5.0_12-b04 64 bit
Reporter: P Eger
Assigned To: Bela Ban
Attachments: stacktrace.txt, tcp-config.xml
RpcDispatcher.callRemoteMethods() hangs, while there is a lot of member churn at the time (4 servers starting into a cluster of 4). 1 of the 4 server starting up is hung with the attached stack trace.
-------------------------------------------------------------------
channel=new JChannel(jgroups_config_file);
channel.setOpt(Channel.AUTO_RECONNECT, Boolean.TRUE);
channel.addChannelListener(this);
//TODO: verify these startup params
//NOTE: deadlock detection leaks memory as of 2.5b2, do not use
disp=new RpcDispatcher(channel, null, this, this, false, true);
//force connect
channel.connect(clusterName);
MethodCall mc = new MethodCall("remoteBroadcastAvailability", new Object[]{peer,sequence,serviceStatus,rotationStatus}, new Class[]{Address.class,Long.class,ServiceStatus.class,RotationStatus.class});
disp.callRemoteMethods(channel.getView().getMembers(), mc, GroupRequest.GET_ALL, 0);
-------------------------------------------------------------------
Name: main
State: WAITING on java.util.HashMap@2d95bbec
Total blocked: 53 Total waited: 12
Stack trace:
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:474)
org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:479)
org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:190)
org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:430)
org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:199)
org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:167)
org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:163)
utils.cluster.PeerClusterManager.broadcastAvailability(PeerClusterManager.java:1110)
utils.cluster.PeerClusterManager.broadcastMyAvailability(PeerClusterManager.java:428)
init.InitManager.ensureInitialized(InitManager.java:552)
init.InitManager.__init(InitManager.java:409)
init.InitManager.init(InitManager.java:300)
init.ServletListener.contextInitialized(ServletListener.java:23)
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3669)
org.apache.catalina.core.StandardContext.start(StandardContext.java:4104)
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
org.apache.catalina.core.StandardService.start(StandardService.java:450)
org.apache.catalina.core.StandardServer.start(StandardServer.java:683)
org.apache.catalina.startup.Catalina.start(Catalina.java:537)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271)
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JGRP-621) JOIN_RSP should interrupt thread blocking down on findInitialMembers
by Vladimir Blagojevic (JIRA)
JOIN_RSP should interrupt thread blocking down on findInitialMembers
--------------------------------------------------------------------
Key: JGRP-621
URL: http://jira.jboss.com/jira/browse/JGRP-621
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
When clients attempts to join it loops through:
while(!joined){
fetch the initial members
determine coordinator
send join request to coordinator
wait for join response (timeout)
if(joinok)
joined = installView
}
Unlucky timing of join response arrival can delay successful view installation and lead to unforeseen problems. If waiting for join response timeouts then joining thread repeats a loop and sends a blocking request to fetch initial members again. If response arrives while joining thread is fetching for the initial members then joining thread has to wait for fetching of the initial members to return in order to proceed with view installation.
Fix for this issue should ensure that If successful join response arrives then joining thread should be interrupted and proceed with view installation immediately.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (GPD-186) ArrayIndexOutOfBoundsException when adding second incoming transition to a node
by Matthias Hanisch (JIRA)
ArrayIndexOutOfBoundsException when adding second incoming transition to a node
-------------------------------------------------------------------------------
Key: GPD-186
URL: http://jira.jboss.com/jira/browse/GPD-186
Project: JBoss jBPM GPD
Issue Type: Bug
Components: jpdl
Environment: Windows 2000, Eclipse 3.3.1.1, GEF 3.3.1 (org.eclipse.gef_3.2.101.v20070814.jar)
Reporter: Matthias Hanisch
Assigned To: Koen Aers
The fixes in issue 169 seem to help to some extent, but they seem to introduce another problem:
When I add a second incoming transition to a node I get the following exception in Error Log View:
java.lang.IndexOutOfBoundsException: Index: 1, Size: 0
at java.util.ArrayList.add(ArrayList.java:368)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.primAddTargetConnection(AbstractGraphicalEditPart.java:532)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.addTargetConnection(AbstractGraphicalEditPart.java:265)
at org.eclipse.gef.editparts.AbstractGraphicalEditPart.refreshTargetConnections(AbstractGraphicalEditPart.java:667)
at org.jbpm.gd.common.part.AbstractNodeGraphicalEditPart.propertyChange(AbstractNodeGraphicalEditPart.java:62)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:333)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:270)
at org.jbpm.gd.common.notation.AbstractNotationElement.firePropertyChange(AbstractNotationElement.java:32)
at org.jbpm.gd.common.notation.Node.addArrivingEdge(Node.java:47)
at org.jbpm.gd.jpdl.notation.JpdlNode.propertyChange(JpdlNode.java:39)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:333)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:270)
at org.jbpm.gd.common.model.AbstractSemanticElement.firePropertyChange(AbstractSemanticElement.java:20)
at org.jbpm.gd.jpdl.model.AbstractNode.addTransition(AbstractNode.java:56)
at org.jbpm.gd.jpdl.command.EdgeCreateCommand.execute(EdgeCreateCommand.java:40)
at org.eclipse.gef.commands.CommandStack.execute(CommandStack.java:149)
at org.eclipse.gef.tools.AbstractTool.executeCommand(AbstractTool.java:388)
at org.eclipse.gef.tools.AbstractTool.executeCurrentCommand(AbstractTool.java:400)
at org.eclipse.gef.tools.AbstractConnectionCreationTool.handleCreateConnection(AbstractConnectionCreationTool.java:241)
at org.eclipse.gef.tools.ConnectionCreationTool.handleButtonDown(ConnectionCreationTool.java:73)
at org.eclipse.gef.tools.AbstractTool.mouseDown(AbstractTool.java:964)
at org.eclipse.gef.EditDomain.mouseDown(EditDomain.java:215)
at org.eclipse.gef.ui.parts.DomainEventDispatcher.dispatchMousePressed(DomainEventDispatcher.java:342)
at org.eclipse.draw2d.LightweightSystem$EventHandler.mouseDown(LightweightSystem.java:513)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:178)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:169)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
at org.eclipse.equinox.launcher.Main.main(Main.java:1148)
Look in AbstractGraphicalEditPart.addTargetConnection():
If connection.getTarget() == this, then the connection is added at first, and then removed again.
When it is then called the second time, we create an IndexOutOfBounds, because it tries to add the connection at the second position.
The root cause seems to be the changes from 1.1 to 1.2 in EdgeGraphicalEditPart.propertyChange.
Here the target of the connection is set and later AbstractGraphicalEditPart.addTargetConnection() is called, which has no effect then.
Sorry, all I can say, that removing this "else if" does not cause any exceptions, but probably it also disables a fix. My knowledge in these areas is too poor to a give a concrete solution, but maybe it helps you to track this. If you need further information just ask.
Again, a more detailed description how I reproduced it:
Open a new process definition, add a start, an end and a task node.
Create a transition from start to end, then from task to end -> exception above.
Commenting the handling of "target" in EdgeGraphicalEditPart.propertyChange() (in my tree lines 117-119) cures that, but may reopen the issue 169.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month