[JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-1389:
----------------------------------
Scott, I'm not going to argue about it. You seem to feel bitter about it and you apparently believe that your viewpoint is "common sense" and thus there's no way to pursue the discussion rationally beyond what was already said.
I can tell you that if you're curious about what APIs are visible from a deployment, you can examine (in JConsole) the JBoss Modules MBean corresponding to the service module loader, and find a deployment module and look at its dependencies. That may give you an idea of what facilities are available to applications.
As for the change not being in EAP - assuming that the proper RFE process is followed, it is not unreasonable to expect this change to be backported, same as any requested feature or enhancement.
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
> Key: AS7-1389
> URL: https://issues.jboss.org/browse/AS7-1389
> Project: Application Server 7
> Issue Type: Bug
> Components: Logging
> Affects Versions: 7.0.0.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}.
--
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
12 years, 6 months
[JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments
by Scott Hasse (JIRA)
[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ]
Scott Hasse commented on AS7-1389:
----------------------------------
> We are an application container; we provide application server facilities, many of them above and beyond Java EE.
Can you provide specific examples of this for a JEE web app for instance? https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Appli... would seem to imply that the only outliers in terms of being explicitly provided outside of the spec are related to logging. Likewise neither EJB3 nor EE deployments seem to have anything implicitly provided beyond the spec except for logging. So for the topic at hand (JEE deployments) I'm not sure what these many above and beyond facilities would be. I'm sure there are other non-JEE deployment types where providing logging might be appropriate, but if that is appropriate for those then by all means provide as many logging APIs and implementations implicitly for them as is appropriate.
Anyway if you are providing vendor-specific facilities above and beyond the spec for JEE apps is it not most reasonable and correct to have the applications making use of those vendor-specific extensions be the ones that have to explicitly specify something?
> I'm sure it will be no trouble for anyone who does not prefer the current behavior to simply flip the switch
I don't believe that switch you suggest we flip currently exists in EAP 6.2 or any currently released EAP. In the mean time every application we develop will need to have a JBoss-specific deployment descriptor embedded, putting it in a non-default and less-well-tested configuration and giving us work to do during future migrations.
> the Java EE specification in no way limits or specifies what secondary APIs we can or should provide to users.
True, but common sense should, and you almost got it fully correct in EAP 6, except it seems for logging.
Regards,
Scott
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
> Key: AS7-1389
> URL: https://issues.jboss.org/browse/AS7-1389
> Project: Application Server 7
> Issue Type: Bug
> Components: Logging
> Affects Versions: 7.0.0.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}.
--
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
12 years, 6 months
[JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-1389:
----------------------------------
{quote}
...basic container/application contract should be the JEE specification... logging is not a JEE facility.... a more correct default would be better than a simple way to change a bad default.
{quote}
None of these arguments really suffices to cause us to change the current default, thus breaking all the apps which currently rely on the current behavior. We are an application container; we provide application server facilities, many of them above and beyond Java EE. That's all there is to it. I'm sure it will be no trouble for anyone who does not prefer the current behavior to simply flip the switch, while allowing those who find the current behavior useful to continue relying on it without breaking compatibility unduly. I'm sorry you do not like it, however I am not convinced that having to flip a switch in the server configuration based on what is obviously a subjective preference is too onerous or justifies a compatibility-breaking change. I believe that this solution lets us accommodate both preferences with ease and without undue burden on the user.
Again, we're an application container. We support a superset of the Java EE specification; and in any case the Java EE specification in no way limits or specifies what secondary APIs we can or should provide to users.
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
> Key: AS7-1389
> URL: https://issues.jboss.org/browse/AS7-1389
> Project: Application Server 7
> Issue Type: Bug
> Components: Logging
> Affects Versions: 7.0.0.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}.
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-2525) Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
by Rossen Stoyanchev (JIRA)
[ https://issues.jboss.org/browse/WFLY-2525?page=com.atlassian.jira.plugin.... ]
Rossen Stoyanchev commented on WFLY-2525:
-----------------------------------------
Okay, I found [the commit|https://github.com/undertow-io/undertow/commit/f8440a534a88ecaea53...] in the Undertow project. The commit is included in Undertow 1.0.0.Beta25 (and 8.0.0.CR1 is running with Beta30). Nevertheless I'm still experiencing the issue. Is it possible the fix is incomplete because the Filter is not configured for DispatcherType.ASYNC? Looking at the implementation of [FilterHandler.java#L55|https://github.com/undertow-io/undertow/blob/1.0.0...], that is expected. Here is a [sample project|https://github.com/rstoyanchev/dispatch-test] I'm using.
> Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-2525
> URL: https://issues.jboss.org/browse/WFLY-2525
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #786 (undertow 1.0.0.beta23)
> atmosphere chat-multiroom sample:
> https://github.com/Atmosphere/atmosphere-samples/tree/master/samples/chat...
> Reporter: John Teller
> Assignee: Stuart Douglas
> Fix For: 8.0.0.CR1
>
>
> In previous Atmosphere tests with undertow beta20, attempting to connect using websocket transport failed, then fell back successfully to long-polling. In latest test with undertow beta23, websocket transport now works correctly, but attempting to connect using long-polling transport now results in the following error:
> 2013-11-17 21:57:32,857 ERROR [org.atmosphere.cpr.AtmosphereFramework] (default task-6) AtmosphereFramework exception: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async
> at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:909) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:503) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:128) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1684) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:184) [atmosphere-runtime-2.0.3.jar:2.0.3]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:114) [undertow-websockets-jsr-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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
12 years, 6 months
[JBoss JIRA] (DROOLS-396) Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
by leonardo lizana (JIRA)
[ https://issues.jboss.org/browse/DROOLS-396?page=com.atlassian.jira.plugin... ]
leonardo lizana updated DROOLS-396:
-----------------------------------
Description:
I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in org/drools/event/DebugProcessEventListener. instead of "org.drools.core.event.DebugProcessEventListener"
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.
Here is my pom.xml
--------------------------
<dependency>
<groupId>org.drools</groupId>
<artifactId>knowledge-api</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-spring</artifactId>
<version>5.5.0.Final</version>
</dependency>
here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:drools="http://drools.org/schema/drools-spring"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-containe..."
default-autowire="byName">
<drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>
<drools:kbase id="kBaseEnergyUsage">
<drools:resources>
<drools:resource ref="rulesEnergyUsage"/>
</drools:resources>
</drools:kbase>
<drools:ksession id="kSessionEnergyUsage" kbase="kBaseEnergyUsage" type="stateful"/>
</beans>
was:
I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in org/drools/event/DebugProcessEventListener. instead of org.drools.core.event.DebugProcessEventListener
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.
Here is my pom.xml
--------------------------
<dependency>
<groupId>org.drools</groupId>
<artifactId>knowledge-api</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-spring</artifactId>
<version>5.5.0.Final</version>
</dependency>
here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:drools="http://drools.org/schema/drools-spring"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-containe..."
default-autowire="byName">
<drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>
<drools:kbase id="kBaseEnergyUsage">
<drools:resources>
<drools:resource ref="rulesEnergyUsage"/>
</drools:resources>
</drools:kbase>
<drools:ksession id="kSessionEnergyUsage" kbase="kBaseEnergyUsage" type="stateful"/>
</beans>
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-396
> URL: https://issues.jboss.org/browse/DROOLS-396
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Reporter: leonardo lizana
> Assignee: Mark Proctor
> Priority: Critical
>
> I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in org/drools/event/DebugProcessEventListener. instead of "org.drools.core.event.DebugProcessEventListener"
> is there anything that i'm doing bad?
> * with drools 5.5 everything is working OK.
> Here is my pom.xml
> --------------------------
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>knowledge-api</artifactId>
> <version>${drools.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>${drools.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <version>${drools.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-spring</artifactId>
> <version>5.5.0.Final</version>
> </dependency>
> here is the log error:
> ----------------------------
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
> at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
> at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
> at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
> at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
> at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
> at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
> at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
> at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
> Here is the contex-drools.xml
> -------------------------------------
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:context="http://www.springframework.org/schema/context"
> xmlns:drools="http://drools.org/schema/drools-spring"
> xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
> http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
> http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-containe..."
> default-autowire="byName">
>
> <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>
> <drools:kbase id="kBaseEnergyUsage">
> <drools:resources>
> <drools:resource ref="rulesEnergyUsage"/>
> </drools:resources>
> </drools:kbase>
> <drools:ksession id="kSessionEnergyUsage" kbase="kBaseEnergyUsage" type="stateful"/>
> </beans>
--
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
12 years, 6 months