[JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4047:
---------------------------------
Assignee: Alessio Soldano (was: Jason Greene)
> SLSB with WebService Annotation generates duplicate endpoint when JMS transport used
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4047
> URL: https://issues.jboss.org/browse/WFLY-4047
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Reporter: Wojciech Oczkowski
> Assignee: Alessio Soldano
> Attachments: TestWSJMS.zip
>
>
> When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached (it requires additional Spring libraries for CXF and JMS transport).
> 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72]
> Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a <jms:destination name="{http://test.ctdp.pl/}NewSessionBeanPort.jms-destination"> and set the jndiConnectionFactoryName ?
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371)
> at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539)
> at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> ... 5 more
> Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a <jms:destination name="{http://test.ctdp.pl/}NewSessionBeanPort.jms-destination"> and set the jndiConnectionFactoryName ?
> at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115)
> at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119)
> at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49)
> at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95)
> at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362)
> ... 13 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS commented on JGRP-1876:
------------------------------------
I'm trying to address the original issue for which I created this issue.
*Issue description*
*T-0* : C is isolated from A and B. So two views are installed : {noformat}[A|1](2){A,B} on (A,B) and [C|0](1){C} on (C){noformat}
*T-1* : Stop isolation of C
*T-2* : C detects inconsistent views {noformat}([A|1] vs [C|0]){noformat} based only on MergeInfo coming from B and itself (C)
but without A's MergeInfo in spite of being a coord because it was sent while C was still isolated.
*T-3* : C decides to install new view {noformat}[C|A]{2){C,B}{noformat}. All members install C's view except A since it isn't in that view.
{noformat}
A : [A|1](2){A,B}
B : [C|A]{2){C,B}
C : [C|A]{2){C,B}
{noformat}
*T-4* : A detects that view are still incoherent (asymmetric). It decides to merge again. Resulting view: {noformat}[A|2](3){A,B,C}{noformat}
*Effects*
1/ When network problem (isolation, flapping, etc) occurs on one member, all other members (like B) may lose their coord.
2/ Two coord changes occurred : A -> C -> A
3/ C installs strange mergeview subgroups: {noformat} [A|1](1)(B), [A|1](1)[D], [A|1](1)[E], ..., [C|0](1)[C]. {noformat} (see enclosed file "MergeViewWith210Subgroups.log").
*Fix*
Only the third effect had been fixed thanks to your patch.
Please take a look at the [PR|https://github.com/belaban/JGroups/pull/200] that should fix the root cause.
Principle: If the merge leader didn't receive a MergeInfo from a real coord (present in a viewId), it checks the "age" of oldest viewId received.
If viewId is not really old (age < check_interval-min_interval), we interrupt merge process.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6, 3.6.2
>
> Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt
>
>
> 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.11#6341)
11 years, 4 months
[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-868:
--------------------------------------------------
Ondrej Kotek <okotek(a)redhat.com> changed the Status of [bug 1173492|https://bugzilla.redhat.com/show_bug.cgi?id=1173492] from ON_QA to VERIFIED
> Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-868
> URL: https://issues.jboss.org/browse/SECURITY-868
> Project: PicketBox
> Issue Type: Task
> Components: PicketBox
> Reporter: Jim Ma
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_9_0.Beta3
>
>
> When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-671) KnowledgeBaseAdapter in legacy 5.x API is not serializable
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-671?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-671:
------------------------------------
Added empty KnowledgeBaseAdapter constructor KnowledgeBaseAdapter with KnowledgeBaseAdapter
> KnowledgeBaseAdapter in legacy 5.x API is not serializable
> ----------------------------------------------------------
>
> Key: DROOLS-671
> URL: https://issues.jboss.org/browse/DROOLS-671
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final
>
>
> Trying to serialize a KnowledgeBase created with the legacy 5.x API causes the following exception.
> java.io.NotSerializableException: org.drools.impl.adapters.KnowledgeBaseAdapter
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4279) JMS Webservice deployed as POJO not EJB even when in @Stateless anotated class
by Wojciech Oczkowski (JIRA)
Wojciech Oczkowski created WFLY-4279:
----------------------------------------
Summary: JMS Webservice deployed as POJO not EJB even when in @Stateless anotated class
Key: WFLY-4279
URL: https://issues.jboss.org/browse/WFLY-4279
Project: WildFly
Issue Type: Bug
Components: Web Services
Affects Versions: 8.1.0.Final
Reporter: Wojciech Oczkowski
Assignee: Alessio Soldano
JMS webservices implemented as Stateless Session Bean's are deployed as JAXWS_JSE Endpoints, so they cannot use EJB features like @EJB based injection or transactional processing.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4278) byte[] saved to Oracle BLOB can not be read back
by Lubos Pechac (JIRA)
[ https://issues.jboss.org/browse/WFLY-4278?page=com.atlassian.jira.plugin.... ]
Lubos Pechac updated WFLY-4278:
-------------------------------
Attachment: wildfly-testcase.zip
Test case deployable to WildFly-8.2.0.Final
> byte[] saved to Oracle BLOB can not be read back
> ------------------------------------------------
>
> Key: WFLY-4278
> URL: https://issues.jboss.org/browse/WFLY-4278
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 8.2.0.Final
> Environment: Linux 64bit, Oracle JDK 7 or 8, WildFly 8.2.0.Final
> Reporter: Lubos Pechac
> Assignee: Scott Marlow
> Attachments: wildfly-testcase.zip
>
>
> Since upgrading to Wildfly (Hibernate 4.3.7) we are experiencing problems persisting certain entities to an Oracle database.
> The entity contains an attribute of type java.lang.Serializable and is mapped to an Oracle BLOB column.
> When the value of the Serializable attribute is a byte[] then this is not properly serialized to the database.
> The value stored does not correspond to the Java Object Serialization Specification, instead the exact contents of the byte array are saved, without the usual header information associated with Java Object Serialization.
>
> When we try to read this back from the database into our entity we get the exception shown below, so basically Hibernate cannot read what it wrote.
>
> We have attached a test case to demonstrate this problem.
>
> Caused by: org.hibernate.type.SerializationException: could not deserialize
> at org.hibernate.internal.util.SerializationHelper.doDeserialize(SerializationHelper.java:262) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.util.SerializationHelper.deserialize(SerializationHelper.java:306) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.fromBytes(SerializableTypeDescriptor.java:155) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:130) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:44) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.sql.VarbinaryTypeDescriptor$2.doExtract(VarbinaryTypeDescriptor.java:71) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:267) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:263) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:338) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2969) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.loadFromResultSet(EntityReferenceInitializerImpl.java:324) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.hydrateEntityState(EntityReferenceInitializerImpl.java:251) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:107) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:255) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:129) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.entity.plan.LegacyBatchingEntityLoaderBuilder$LegacyBatchingEntityLoader.load(LegacyBatchingEntityLoaderBuilder.java:130) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final]
> ... 183 more
> Caused by: java.io.StreamCorruptedException: invalid stream header: 63726561
> at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:804) [rt.jar:1.7.0_71]
> at java.io.ObjectInputStream.<init>(ObjectInputStream.java:299) [rt.jar:1.7.0_71]
> at org.hibernate.internal.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:328) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:318) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.util.SerializationHelper.doDeserialize(SerializationHelper.java:237) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> ... 214 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4278) byte[] saved to Oracle BLOB can not be read back
by Lubos Pechac (JIRA)
Lubos Pechac created WFLY-4278:
----------------------------------
Summary: byte[] saved to Oracle BLOB can not be read back
Key: WFLY-4278
URL: https://issues.jboss.org/browse/WFLY-4278
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 8.2.0.Final
Environment: Linux 64bit, Oracle JDK 7 or 8, WildFly 8.2.0.Final
Reporter: Lubos Pechac
Assignee: Scott Marlow
Since upgrading to Wildfly (Hibernate 4.3.7) we are experiencing problems persisting certain entities to an Oracle database.
The entity contains an attribute of type java.lang.Serializable and is mapped to an Oracle BLOB column.
When the value of the Serializable attribute is a byte[] then this is not properly serialized to the database.
The value stored does not correspond to the Java Object Serialization Specification, instead the exact contents of the byte array are saved, without the usual header information associated with Java Object Serialization.
When we try to read this back from the database into our entity we get the exception shown below, so basically Hibernate cannot read what it wrote.
We have attached a test case to demonstrate this problem.
Caused by: org.hibernate.type.SerializationException: could not deserialize
at org.hibernate.internal.util.SerializationHelper.doDeserialize(SerializationHelper.java:262) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.internal.util.SerializationHelper.deserialize(SerializationHelper.java:306) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.fromBytes(SerializableTypeDescriptor.java:155) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:130) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:44) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.descriptor.sql.VarbinaryTypeDescriptor$2.doExtract(VarbinaryTypeDescriptor.java:71) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:267) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:263) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:338) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2969) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.loadFromResultSet(EntityReferenceInitializerImpl.java:324) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.hydrateEntityState(EntityReferenceInitializerImpl.java:251) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:107) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:255) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:129) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.loader.entity.plan.LegacyBatchingEntityLoaderBuilder$LegacyBatchingEntityLoader.load(LegacyBatchingEntityLoaderBuilder.java:130) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final]
... 183 more
Caused by: java.io.StreamCorruptedException: invalid stream header: 63726561
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:804) [rt.jar:1.7.0_71]
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:299) [rt.jar:1.7.0_71]
at org.hibernate.internal.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:328) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.internal.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:318) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
at org.hibernate.internal.util.SerializationHelper.doDeserialize(SerializationHelper.java:237) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
... 214 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used
by Wojciech Oczkowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.... ]
Wojciech Oczkowski commented on WFLY-4047:
------------------------------------------
after digging through source code it seems that JAXWS_JMS Endpoints are deployed as JAXWS_JSE (POJO) webservices, so they are not EJB's at all.
> SLSB with WebService Annotation generates duplicate endpoint when JMS transport used
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4047
> URL: https://issues.jboss.org/browse/WFLY-4047
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Reporter: Wojciech Oczkowski
> Assignee: Jason Greene
> Attachments: TestWSJMS.zip
>
>
> When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached (it requires additional Spring libraries for CXF and JMS transport).
> 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72]
> Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a <jms:destination name="{http://test.ctdp.pl/}NewSessionBeanPort.jms-destination"> and set the jndiConnectionFactoryName ?
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371)
> at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539)
> at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> ... 5 more
> Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a <jms:destination name="{http://test.ctdp.pl/}NewSessionBeanPort.jms-destination"> and set the jndiConnectionFactoryName ?
> at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115)
> at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119)
> at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49)
> at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95)
> at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362)
> ... 13 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months