January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6384) Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception

by Martin Keller (JIRA)

Martin Keller created AS7-6384: ---------------------------------- Summary: Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception Key: AS7-6384 URL: https://issues.jboss.org/browse/AS7-6384 Project: Application Server 7 Issue Type: Bug Components: JCA Affects Versions: 7.2.0.Alpha1 Environment: Configuration: JDK-Version: 1.6.0_33 Operating System: Windows 7 (32 Bit) JBoss Application Server jboss-as-7.2.0.Alpha1-SNAPSHOT (build Dec. 19th 2012) JDK-Version: 1.6.0_33 Resource Adapter: BeanConnect 3.0 developed by our Company (Fujitsu) Reporter: Martin Keller Assignee: Jesper Pedersen Starting an application using our JCA 1.6 resource adapter fails with java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception It works ok in the JBoss JCA 1.5 environment and on other application servers with JCA1.6 environment: GlassFish OS Edition 3, IBM WebSphere 8.0 and WebLogic 12. Questions: What could be the cause for this exception? Can we switch off the validation? What is missing to run the validation successful? Details: The full stack is: 15:04:02,128 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 64) MSC00001: Failed to start service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_33] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33] at org.jboss.threads.JBossThread.run(JBossThread.java:122) Caused by: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:177) at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] ... 7 more Caused by: javax.resource.ResourceException: IJ000852: Validation exception at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:147) at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:175) ... 8 more Caused by: javax.validation.ValidationException: Unable to find a default provider at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264) [validation-api-1.0.0.GA.jar:] at org.jboss.jca.core.bv.BeanValidationUtil.createValidatorFactory(BeanValidationUtil.java:51) at org.jboss.jca.core.bv.BeanValidationUtil.createValidator(BeanValidationUtil.java:63) at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:135) ... 9 more -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3452) Bugs when refactoring class and field names in the eclipse plugin

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3452?page=com.atlassian.jira.plug... ] Mario Fusco resolved JBRULES-3452. ---------------------------------- Resolution: Done > Bugs when refactoring class and field names in the eclipse plugin > ----------------------------------------------------------------- > > Key: JBRULES-3452 > URL: https://issues.jboss.org/browse/JBRULES-3452 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > When the name of a java class (or one of its field) used in the DRLs is refactored, the corresponding name replacement in the DRLs themselves often makes them wrong/unusable. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3668) Allow to create KJars both programmatically and with a maven plugin

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3668?page=com.atlassian.jira.plug... ] Mario Fusco resolved JBRULES-3668. ---------------------------------- Resolution: Done > Allow to create KJars both programmatically and with a maven plugin > ------------------------------------------------------------------- > > Key: JBRULES-3668 > URL: https://issues.jboss.org/browse/JBRULES-3668 > Project: JBRULES > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > Add a mechanism for creating a Kjar, i.e. a jar containing all the information necessary to create already configured kbases and ksessions and refers to them using a unique name, both programmatically and with a maven plugin -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3522) Publish rule meta data about what it modifies, inserts or retracts

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3522?page=com.atlassian.jira.plug... ] Mario Fusco resolved JBRULES-3522. ---------------------------------- Resolution: Done > Publish rule meta data about what it modifies, inserts or retracts > ------------------------------------------------------------------ > > Key: JBRULES-3522 > URL: https://issues.jboss.org/browse/JBRULES-3522 > Project: JBRULES > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > To allow to create rule chaining graphs and better detect circular issues, it is necessary to add some meta data to the Rule class describing which class of facts its consequence inserts, modifies or retracts. For both insertions and modifications it is also requested to determine the fields involved and whether they are populated with literals or variables. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3179) Create a micro benchmarking suite

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3179?page=com.atlassian.jira.plug... ] Mario Fusco resolved JBRULES-3179. ---------------------------------- Resolution: Done > Create a micro benchmarking suite > --------------------------------- > > Key: JBRULES-3179 > URL: https://issues.jboss.org/browse/JBRULES-3179 > Project: JBRULES > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > Create a micro benchmarking suite, where "micro" means that it is intended to test repeatedly very small aspects of the engine in order to avoid performance regressions. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3672) Split DRL parser in order to support both drl5 and drl6

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3672?page=com.atlassian.jira.plug... ] Mario Fusco resolved JBRULES-3672. ---------------------------------- Resolution: Done > Split DRL parser in order to support both drl5 and drl6 > ------------------------------------------------------- > > Key: JBRULES-3672 > URL: https://issues.jboss.org/browse/JBRULES-3672 > Project: JBRULES > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > > Split DRL parser in order to support both drl5 and drl6 -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6054) Package uses conflict with org.springframework.ldap

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6054?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-6054: -------------------------------- Fix Version/s: (was: 7.2.0.CR1) > Package uses conflict with org.springframework.ldap > --------------------------------------------------- > > Key: AS7-6054 > URL: https://issues.jboss.org/browse/AS7-6054 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.2.0.Alpha1 > Environment: Windows XP SP2 > Oracle JDK 1.6.0_32 > Reporter: Ed Roberts > > I am able to recreate a bundle resolution problem that gives very little help in where the cause lies. > We deploy a set of Spring 3.1.1.RELEASE bundles in the bundles directory structure, exposed through the standalone.xml capabilities. Separately, a set of bundles are located in the deployments folder, and they include/use some Spring 3.0.7.RELEASE; e.g. beans and core. The reason for the duplication is because a particular LDAP bundle does not work with the later spring bundles. When I deploy the spring-security-ldap-3.1.1.RELEASE.jar in the deployments folder, I get the following WARNING in the console/log file > {code} > 2012-11-27 16:24:13,808 WARN [org.jboss.as.osgi](MSC service thread 1-5) JBAS011910: Cannot resolve requirements: [] > {code} > The cause of the issue was located during a debug session, to be > {code} > Chain 1: > org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]] > import: null > | > export: osgi.wiring.package=org.springframework.beans > org.springframework.beans [HostBundleRevision[org.springframework.beans:3.0.7.RELEASE]] > Chain 2: > org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]] > import: null > | > export: osgi.wiring.package=org.springframework.context.support; uses:=org.springframework.beans > org.springframework.context [HostBundleRevision[org.springframework.context:3.1.1.RELEASE]] > import: null > | > export: osgi.wiring.package=org.springframework.beans > org.springframework.beans [HostBundleRevision[org.springframework.beans:3.1.1.RELEASE]] > {code} > It seems that when there are multiple providers of a requirement, the requiring bundle is deemed invalid. That doesn't seem correct. Should it not just choose the first valid provider ? Either way, when the Unresolved Bundles are empty in BundleResolveProcessor, the details of the multiple providers should at least be logged as an ERROR as it prevents the bundle from being successfully resolved. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-5958) Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-5958: -------------------------------- Fix Version/s: (was: 7.2.0.CR1) > Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles > ----------------------------------------------------------------------------------------------------------------------- > > Key: AS7-5958 > URL: https://issues.jboss.org/browse/AS7-5958 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.2.0.Alpha1 > Environment: Windows XP SP3 > Reporter: Paul Illingworth > Labels: OSGI > > I am getting the following exception when my bundle is being resolved. I don't believe this is correct. > {noformat} > 2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate permutation failed due to a conflict between imports; will try another if possible.: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package 'com.google.inject' from resources com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains. > Chain 1: > resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] > import: null > | > export: osgi.wiring.package=com.google.inject > com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] > Chain 2: > resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] > import: null > | > export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets; uses:=com.google.inject > reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]] > import: null > | > export: osgi.wiring.package=com.google.inject > com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] > at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142) > at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197) > at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56) > at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152) > at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167) > at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598) > at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214) > at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520) > at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437) > at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384) > 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:597) > at org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209) > at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source) > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547) > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480) > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70) > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520) > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227) > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941) > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117) > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409) > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186) > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875) > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74) > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110) > at org.eclipse.jetty.server.Server.handle(Server.java:349) > at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441) > at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224) > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51) > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586) > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44) > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598) > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533) > at java.lang.Thread.run(Thread.java:662) > 2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release framework lock > {noformat} > It seems to be happening because the ResolverImpl.isCompatible() method is comparing two capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that contains the same instance of AbstractBundleCapability. The result of the comparison is false. > As a quick hack I changed the equals method of WrappedCapability to > {noformat} > @Override > public boolean equals(Object obj) > { > return m_cap.equals(obj); > } > {noformat} > and that seemed to make it work and resolution was successful. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-17) When a new rule is dynamically added the new Left and Right tuples are added always at the end

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-17?page=com.atlassian.jira.plugin.... ] Mario Fusco resolved DROOLS-17. ------------------------------- Fix Version/s: 6.0.0.Alpha1 Resolution: Done > When a new rule is dynamically added the new Left and Right tuples are added always at the end > ---------------------------------------------------------------------------------------------- > > Key: DROOLS-17 > URL: https://issues.jboss.org/browse/DROOLS-17 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.0.Alpha1 > > > When a new rule is dynamically added the new Left and Right tuples it eventually creates are added always at the end instead of being inserted in the correct position in the respective lists. -- 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

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6279) Misspelled system property FRAMEWORK_VENDOR "org.osgi.vendor.framework"

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6279?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-6279: -------------------------------- Fix Version/s: 7.2.0.Alpha1 > Misspelled system property FRAMEWORK_VENDOR "org.osgi.vendor.framework" > ----------------------------------------------------------------------- > > Key: AS7-6279 > URL: https://issues.jboss.org/browse/AS7-6279 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.1.Final > Reporter: Andreas Weise > Assignee: Thomas Diesler > Priority: Minor > Fix For: 7.2.0.Alpha1 > > > JBoss AS 7 uses misspelled system property for OSGi constant FRAMEWORK_VENDOR which is not defined by OSGi spec. > Reference http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Constants.html defines for constant FRAMEWORK_VENDOR: > "org.osgi.framework.vendor" > Jboss uses: > "org.osgi.vendor.framework" -- 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

13 years, 5 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 January 2013