[JBoss JIRA] (AS7-3080) Infinispan CacheManager not available in JNDI at JPA subsystem startup
by Brent Douglas (Created) (JIRA)
Infinispan CacheManager not available in JNDI at JPA subsystem startup
----------------------------------------------------------------------
Key: AS7-3080
URL: https://issues.jboss.org/browse/AS7-3080
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.0.CR1
Reporter: Brent Douglas
Assignee: Scott Marlow
CacheManager is not available in JNDI at JPA subsystem startup. Seems likely to be related to AS7-1656.
Relevant section of startup logs:
10:56:41,036 INFO [org.hibernate.transaction.TransactionFactoryFactory] (MSC service thread 1-1) Transaction strategy: org.hibernate.ejb.transaction.JoinableCMTTransactionFactory
10:56:41,036 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] (MSC service thread 1-1) instantiating TransactionManagerLookup: org.jboss.as.jpa.hibernate3.JBossAppServerJtaPlatform
10:56:41,036 INFO [org.hibernate.transaction.TransactionManagerLookupFactory] (MSC service thread 1-1) instantiated TransactionManagerLookup
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Automatic flush during beforeCompletion(): disabled
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Automatic session close at end of transaction: disabled
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) JDBC batch size: 15
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) JDBC batch updates for versioned data: disabled
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Scrollable result sets: enabled
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) JDBC3 getGeneratedKeys(): enabled
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Connection release mode: auto
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Maximum outer join fetch depth: 3
10:56:41,036 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Default batch fetch size: 8
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Generate SQL with comments: disabled
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Order SQL updates by primary key: disabled
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Order SQL inserts for batching: disabled
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
10:56:41,037 INFO [org.hibernate.hql.ast.ASTQueryTranslatorFactory] (MSC service thread 1-1) Using ASTQueryTranslatorFactory
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Query language substitutions: {}
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) JPA-QL strict compliance: enabled
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Second-level cache: enabled
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Query cache: enabled
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Cache region factory : org.hibernate.cache.infinispan.JndiInfinispanRegionFactory
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Optimize cache for minimal puts: enabled
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Cache region prefix: pluto-resources.ear#PlutoMainPU
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Structured second-level cache entries: enabled
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Query cache factory: org.hibernate.cache.StandardQueryCacheFactory
10:56:41,037 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Statistics: disabled
10:56:41,038 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Deleted entity synthetic identifier rollback: disabled
10:56:41,038 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Default entity-mode: pojo
10:56:41,038 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Named query checking : enabled
10:56:41,038 INFO [org.hibernate.cfg.SettingsFactory] (MSC service thread 1-1) Check Nullability in Core (should be disabled when Bean Validation is on): disabled
10:56:41,285 INFO [org.hibernate.impl.SessionFactoryImpl] (MSC service thread 1-1) building session factory
10:56:41,285 INFO [org.hibernate.type.BasicTypeRegistry] (MSC service thread 1-1) Type registration [materialized_blob] overrides previous : org.hibernate.type.MaterializedBlobType@4863d8a7
10:56:41,286 INFO [org.hibernate.cache.infinispan.JndiInfinispanRegionFactory] (MSC service thread 1-1) Unable to retrieve CacheManager from JNDI [java:jboss/infinispan/hibernate]: javax.naming.NameNotFoundException: Error looking up infinispan/hibernate, service service jboss.naming.context.java.jboss.infinispan.hibernate is not started
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:121) [jboss-as-naming-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74) [jboss-as-naming-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:177) [jboss-as-naming-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:97) [jboss-as-naming-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:213) [jboss-as-naming-7.1.0.CR1-SNAPSHOT.jar:]
at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
at org.hibernate.cache.infinispan.JndiInfinispanRegionFactory.locateCacheManager(JndiInfinispanRegionFactory.java:75) [hibernate-infinispan-3.6.7.Final.jar:]
at org.hibernate.cache.infinispan.JndiInfinispanRegionFactory.createCacheManager(JndiInfinispanRegionFactory.java:68) [hibernate-infinispan-3.6.7.Final.jar:]
at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:256) [hibernate-infinispan-3.6.7.Final.jar:]
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:238) [hibernate-core-3.6.7.Final.jar:]
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1872) [hibernate-core-3.6.7.Final.jar:]
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:906) [hibernate-entitymanager-3.6.7.Final.jar:]
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:74) [hibernate-entitymanager-3.6.7.Final.jar:]
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:149) [jboss-as-jpa-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.start(PersistenceUnitServiceImpl.java:79) [jboss-as-jpa-7.1.0.CR1-SNAPSHOT.jar:]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
10:56:41,287 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.persistenceunit."pluto-resources.ear#PlutoMainPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."pluto-resources.ear#PlutoMainPU": Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780) [jboss-msc-1.0.1.GA.jar:]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
Caused by: javax.persistence.PersistenceException: [PersistenceUnit: PlutoMainPU] Unable to build EntityManagerFactory
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:915)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:74)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:149)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.start(PersistenceUnitServiceImpl.java:79)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:]
... 3 more
Caused by: org.hibernate.cache.CacheException: Unable to retrieve CacheManager from JNDI [java:jboss/infinispan/hibernate]
at org.hibernate.cache.infinispan.JndiInfinispanRegionFactory.locateCacheManager(JndiInfinispanRegionFactory.java:79)
at org.hibernate.cache.infinispan.JndiInfinispanRegionFactory.createCacheManager(JndiInfinispanRegionFactory.java:68)
at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:256)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:238)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1872)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:906)
... 8 more
10:56:41,507 INFO [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Deployment of "pluto-resources.ear" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"pluto-resources.ear#PlutoIdentityPU\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"pluto-resources.ear#PlutoIdentityPU\": Failed to start service","jboss.persistenceunit.\"pluto-resources.ear#PlutoMainPU\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"pluto-resources.ear#PlutoMainPU\": Failed to start service"}}
10:56:41,738 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) Stopped deployment pluto-interop.jar in 237ms
10:56:41,739 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) Stopped deployment pluto-framework.jar in 239ms
10:56:41,741 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) Stopped deployment pluto-rest.war in 241ms
10:56:41,773 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) Stopped deployment pluto-resources.ear in 273ms
10:56:41,775 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
JBAS014777: Services which failed to start: service jboss.persistenceunit."pluto-resources.ear#PlutoIdentityPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."pluto-resources.ear#PlutoIdentityPU": Failed to start service
service jboss.persistenceunit."pluto-resources.ear#PlutoMainPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."pluto-resources.ear#PlutoMainPU": Failed to start service
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5064) Dependencies auto-activated from persistence.xml cannot be excluded in jboss-deployment-structure.xml
by Craig Ringer (JIRA)
Craig Ringer created AS7-5064:
---------------------------------
Summary: Dependencies auto-activated from persistence.xml cannot be excluded in jboss-deployment-structure.xml
Key: AS7-5064
URL: https://issues.jboss.org/browse/AS7-5064
Project: Application Server 7
Issue Type: Bug
Components: Class Loading, JPA / Hibernate
Affects Versions: 7.1.1.Final
Environment: $ java -version
java version "1.7.0_03-icedtea"
OpenJDK Runtime Environment (fedora-2.2.1.fc17.8-x86_64)
OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)
$ lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 17 (Beefy Miracle)
Release: 17
Codename: BeefyMiracle
$ uname -a
Linux thehostname.localdomain 3.4.2-4.fc17.x86_64 #1 SMP Thu Jun 14 22:22:05 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Craig Ringer
Assignee: David Lloyd
An a dependency added automatically by AS7 using persistence provider detection cannot be excluded using jboss-deployment-structure.xml . The exclusion takes effect but does so incorrectly, producing a non-functional deployment where the persistence provider module still gets activated (if present) but cannot see its own classes via the deployment's classloader.
If the persistence provider module is not present, the deployment will fail with a missing dependency even when the automatic dependency has been excluded.
This behaviour renders it apparently impossible to package a persistence provider in a deployment's /WEB-INF/lib/ directory. If you want to do automated integration testing (say, with Arquillian) that makes it pretty impractical. Additionally, the half-excluded state is clearly just broken.
DETAIL
------
JBoss's module loader automatically adds dependencies on persistence providers declared in <provider/> entries in deployments' persistence.xml files. That's fine if a module for the provider is installed, but it also adds dependencies on modules that are *not* installed.
The mapping from provider to module is in jpa/core/src/main/java/org/jboss/as/jpa/config/Configuration.java and seems to be used by jpa/core/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java to add the dependency.
If a jboss-deployment-structure.xml excludes the automatically added dependency, AS7 still tries to load the module and use it. If the module isn't present (as many of the persistence provider modules aren't) this will fail the deployment.
If the module *is* present, the exclusion prevents the module from being visible on the deployment's classpath. If the persistence provider ever tries to access its classes via the classloader context of the depoyment (which it will) this will fail with ClassNotFoundException.
I'll add a test case soon.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-3536) Review the inter-module dependencies directly relating to domain security
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-3536:
-------------------------------------
Summary: Review the inter-module dependencies directly relating to domain security
Key: AS7-3536
URL: https://issues.jboss.org/browse/AS7-3536
Project: Application Server 7
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
The domain-management module containing a lot of the Remoting/SASL security services was added after a lot of the other inter-module dependencies had been established, now before the next major phase of development need to review the resulting dependencies and clean up.
Most notably the API/SPI aspect of the security classes should be better separated from the domain operations acting on them - there are numerous places where access to the API is required or other services need to implement an SPI interface but the close coupling of management operations causes cyclic dependency issues.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-4843) Hornetq adapter doesn't implement ActivationConfigProperty DeliveryActive
by Prasad Deshpande (JIRA)
Prasad Deshpande created AS7-4843:
-------------------------------------
Summary: Hornetq adapter doesn't implement ActivationConfigProperty DeliveryActive
Key: AS7-4843
URL: https://issues.jboss.org/browse/AS7-4843
Project: Application Server 7
Issue Type: Bug
Components: EE, EJB, JMS
Affects Versions: 7.1.2.Final (EAP), 7.1.1.Final
Environment: Windows 64 bit
Reporter: Prasad Deshpande
Assignee: David Lloyd
I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
16:04:30,794 WARN [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
Thanks,
Prasad
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (JBRULES-3559) Memory leakage when no transaction manager is used
by Fabio Strozzi (JIRA)
Fabio Strozzi created JBRULES-3559:
--------------------------------------
Summary: Memory leakage when no transaction manager is used
Key: JBRULES-3559
URL: https://issues.jboss.org/browse/JBRULES-3559
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.4.0.Final, 5.3.1.Final
Environment: JBPM 5.2.Final, Drools 5.3.1.Final, Weblogic 10.3.5, JRockit R28.2.2-7-148152-1.6.0_29-20111221-2104-linux-x86_64, Spring 3.0.5
Reporter: Fabio Strozzi
Assignee: Mark Proctor
Hi,
a memory leak appears in Drools if a StatefulKnowledgeSession is created without a transaction manager being speciifed (despite the fact that the dispose method is called for each session, be it created or loaded).
To be more clear, this is the code that creates the session:
Environment env = KnowledgeBaseFactory.newEnvironment();
env.set(EnvironmentName.ENTITY_MANAGER_FACTORY, emf);
return JPAKnowledgeService.newStatefulKnowledgeSession(readKnowledgeBase(), null, env);
When analyzing the memory dumps of a Spring-based webapplication that uses JBPM, under stress conditions, the Eclipse Memory Analyzer blames org.drools.persistence.SingleSessionCommandService class as the main cause of the leakage. This class is taking up to the 46% of the whole heap by accumulating instances of java.lang.Object[] arrays. These arrays are actually elements of a synchronized map called sysnchronizations (see SingleSessionCommandService.java, line 73).
For my understanding of the source code of Drools, the sysnchronizations map is filled every time the registerRollbackSync method of SingleSessionCommandService is called; on the other hand, its elements are removed only if a JtaTransactionSynchronizationAdapter is successfully registered against the transaction (via javax.transaction.Transaction.registerSynchronization method).
If I understand it correctly, this happens only if a javax.transaction.TransactionManager object is specified in the environment properties or one is found by JtaTransactionManager.findTransactionManager.
When no transaction manager is present (or none is found by findTransactionManager), method SynchronizationImpl.afterCompletion (the only one eligible to remove elements from SingleSessionCommandService.synchronizations) is never called and memory increases with each new session.
Please note that if no transaction synchronization manager is passed as an environement property, then org.drools.persistence.jta.JtaTransactionManager never finds it, even if the JNDI lookup successfully retrieves it; method findTransactionSynchronizationRegistry never sets the tsr attribute, hence if it was null at the time the method is called, so it is when it returns.
I also tried to set the transaction manager but I still get a constant memory consumption. The Eclipse Memory Analyzer claims that, in this case, class org.drools.reteoo.ReteooStatefulSession is suspected for the leakage.
As a final note, there's a minor issue in class JtaTransactionSynchronizationAdapter: at line 31, the afterCompletion method is called on object this rather than on object ts (TransactionSynchronization). This could cause a loop if status is STATUS_ACTIVE.
I'm working on a test case to reproduce the memory issues. I will provide one as soon as possible along with a heap dump.
Fabio
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (LOGMGR-24) Bad level "OFF" when using JDK7
by Jesper Pedersen (JIRA)
Bad level "OFF" when using JDK7
-------------------------------
Key: LOGMGR-24
URL: https://jira.jboss.org/browse/LOGMGR-24
Project: JBoss Log Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.2.0.CR6
Reporter: Jesper Pedersen
Assignee: David Lloyd
When using JDK7 I get
Caused by: java.lang.ExceptionInInitializerError
at sun.util.logging.PlatformLogger.<init>(PlatformLogger.java:164)
at sun.util.logging.PlatformLogger.getLogger(PlatformLogger.java:128)
at sun.net.www.protocol.http.HttpURLConnection.<clinit>(HttpURLConnection.java:298)
at sun.net.www.protocol.http.Handler.openConnection(Handler.java:62)
at sun.net.www.protocol.http.Handler.openConnection(Handler.java:57)
at java.net.URL.openConnection(URL.java:969)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:628)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1292)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:1259)
at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:260)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1169)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1065)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:978)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116)
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:551)
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.nextTag(XMLStreamReaderImpl.java:1234)
at org.jboss.jca.common.metadata.ra.RaParser.parse(RaParser.java:114)
at org.jboss.jca.common.metadata.MetadataFactory.getStandardMetaData(MetadataFactory.java:105)
at org.jboss.jca.deployers.fungal.RADeployer.deploy(RADeployer.java:166)
... 26 more
Caused by: java.lang.IllegalArgumentException: Bad level "OFF"
at java.util.logging.Level.parse(Level.java:355)
at java.util.logging.LoggingProxyImpl.parseLevel(LoggingProxyImpl.java:95)
at sun.util.logging.LoggingSupport.parseLevel(LoggingSupport.java:134)
at sun.util.logging.PlatformLogger$JavaLogger.getLevelObjects(PlatformLogger.java:504)
at sun.util.logging.PlatformLogger$JavaLogger.<clinit>(PlatformLogger.java:496)
... 46 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months