[JBoss JIRA] (WFLY-1622) Update syslog handler attributes
by James Perkins (JIRA)
James Perkins created WFLY-1622:
-----------------------------------
Summary: Update syslog handler attributes
Key: WFLY-1622
URL: https://issues.jboss.org/browse/WFLY-1622
Project: WildFly
Issue Type: Enhancement
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Priority: Minor
The syslog handler does not currently expose the formatter for formatting messages. There will also be changes in a future logmanager release for TCP support and various other properties based on the new TCP support.
--
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
[JBoss JIRA] (WFLY-1621) JPA view in management console is getting "No resource definition is registered for address..."
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1621?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-1621:
-------------------------------
Description:
Reported by ehsavoie on IRC:
{quote}
<ehsavoie> it looks like wildfly is looking for a "hibernate-persistence-unit" element in the jpa subsystem which creates an error 500 on the jpa tab in the admin console with the standalone default configuration. Shouldn't there be a default working config there ?
<smarlow> ehsavoie: sounds like a bug, which build of WildFly?
<ehsavoie> master from this morning
<ehsavoie> the 500 error: http://fpaste.org/22146/
<ehsavoie> smarlow: commit b5367674f6b3efb778fee8baa2739ff8fda4b4a5
<smarlow> ehsavoie: okay, another question, is this with a JPA application deployed?
<ehsavoie> nope, blank standalone from the build
<smarlow> ehsavoie: I'll try to recreate after my (master) build finishes. I usually have some JPA application deployed when I use the management console so I probably missed this
<ehsavoie> smarlow: the error is 'logical' as there are no resource so the context.getFailureDescription().set(MESSAGES.noSuchResourceType(stepAddress)); is not surprising
<smarlow> ehsavoie: thanks, i reproduced it
* fharms has quit (Quit: This computer has gone to sleep)
<ehsavoie> smarlow: you're welcome
{quote}
Internal Server Error
"JBAS014883: No resource definition is registered for address [
(\"deployment\" => \"*\"),
(\"subsystem\" => \"jpa\"),
(\"hibernate-persistence-unit\" => \"*\")
]"
https://gist.github.com/scottmarlow/5902551
was:
Reported by ehsavoie on IRC:
[quote]
<ehsavoie> it looks like wildfly is looking for a "hibernate-persistence-unit" element in the jpa subsystem which creates an error 500 on the jpa tab in the admin console with the standalone default configuration. Shouldn't there be a default working config there ?
<smarlow> ehsavoie: sounds like a bug, which build of WildFly?
<ehsavoie> master from this morning
<ehsavoie> the 500 error: http://fpaste.org/22146/
<ehsavoie> smarlow: commit b5367674f6b3efb778fee8baa2739ff8fda4b4a5
<smarlow> ehsavoie: okay, another question, is this with a JPA application deployed?
<ehsavoie> nope, blank standalone from the build
<smarlow> ehsavoie: I'll try to recreate after my (master) build finishes. I usually have some JPA application deployed when I use the management console so I probably missed this
<ehsavoie> smarlow: the error is 'logical' as there are no resource so the context.getFailureDescription().set(MESSAGES.noSuchResourceType(stepAddress)); is not surprising
<smarlow> ehsavoie: thanks, i reproduced it
* fharms has quit (Quit: This computer has gone to sleep)
<ehsavoie> smarlow: you're welcome
[quote]
Internal Server Error
"JBAS014883: No resource definition is registered for address [
(\"deployment\" => \"*\"),
(\"subsystem\" => \"jpa\"),
(\"hibernate-persistence-unit\" => \"*\")
]"
https://gist.github.com/scottmarlow/5902551
> JPA view in management console is getting "No resource definition is registered for address..."
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-1621
> URL: https://issues.jboss.org/browse/WFLY-1621
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate, Web Console
> Affects Versions: 8.0.0.Alpha2
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> Reported by ehsavoie on IRC:
> {quote}
> <ehsavoie> it looks like wildfly is looking for a "hibernate-persistence-unit" element in the jpa subsystem which creates an error 500 on the jpa tab in the admin console with the standalone default configuration. Shouldn't there be a default working config there ?
> <smarlow> ehsavoie: sounds like a bug, which build of WildFly?
> <ehsavoie> master from this morning
> <ehsavoie> the 500 error: http://fpaste.org/22146/
> <ehsavoie> smarlow: commit b5367674f6b3efb778fee8baa2739ff8fda4b4a5
> <smarlow> ehsavoie: okay, another question, is this with a JPA application deployed?
> <ehsavoie> nope, blank standalone from the build
> <smarlow> ehsavoie: I'll try to recreate after my (master) build finishes. I usually have some JPA application deployed when I use the management console so I probably missed this
> <ehsavoie> smarlow: the error is 'logical' as there are no resource so the context.getFailureDescription().set(MESSAGES.noSuchResourceType(stepAddress)); is not surprising
> <smarlow> ehsavoie: thanks, i reproduced it
> * fharms has quit (Quit: This computer has gone to sleep)
> <ehsavoie> smarlow: you're welcome
> {quote}
> Internal Server Error
> "JBAS014883: No resource definition is registered for address [
> (\"deployment\" => \"*\"),
> (\"subsystem\" => \"jpa\"),
> (\"hibernate-persistence-unit\" => \"*\")
> ]"
> https://gist.github.com/scottmarlow/5902551
--
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
[JBoss JIRA] (WFLY-1621) JPA view in management console is getting "No resource definition is registered for address..."
by Scott Marlow (JIRA)
Scott Marlow created WFLY-1621:
----------------------------------
Summary: JPA view in management console is getting "No resource definition is registered for address..."
Key: WFLY-1621
URL: https://issues.jboss.org/browse/WFLY-1621
Project: WildFly
Issue Type: Feature Request
Components: JPA / Hibernate, Web Console
Affects Versions: 8.0.0.Alpha2
Reporter: Scott Marlow
Assignee: Scott Marlow
Reported by ehsavoie on IRC:
[quote]
<ehsavoie> it looks like wildfly is looking for a "hibernate-persistence-unit" element in the jpa subsystem which creates an error 500 on the jpa tab in the admin console with the standalone default configuration. Shouldn't there be a default working config there ?
<smarlow> ehsavoie: sounds like a bug, which build of WildFly?
<ehsavoie> master from this morning
<ehsavoie> the 500 error: http://fpaste.org/22146/
<ehsavoie> smarlow: commit b5367674f6b3efb778fee8baa2739ff8fda4b4a5
<smarlow> ehsavoie: okay, another question, is this with a JPA application deployed?
<ehsavoie> nope, blank standalone from the build
<smarlow> ehsavoie: I'll try to recreate after my (master) build finishes. I usually have some JPA application deployed when I use the management console so I probably missed this
<ehsavoie> smarlow: the error is 'logical' as there are no resource so the context.getFailureDescription().set(MESSAGES.noSuchResourceType(stepAddress)); is not surprising
<smarlow> ehsavoie: thanks, i reproduced it
* fharms has quit (Quit: This computer has gone to sleep)
<ehsavoie> smarlow: you're welcome
[quote]
Internal Server Error
"JBAS014883: No resource definition is registered for address [
(\"deployment\" => \"*\"),
(\"subsystem\" => \"jpa\"),
(\"hibernate-persistence-unit\" => \"*\")
]"
https://gist.github.com/scottmarlow/5902551
--
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
[JBoss JIRA] (DROOLS-184) kieResources.newClassPathResource() violates the Class.getResource() conventions
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-184?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-184 at 7/1/13 11:44 AM:
------------------------------------------------------------------
Just double checked with Mark, this a bug, not intended design:
<conan_> kieResources.newClassPathResource("src/main/resource/xxx/org/cheese/myCheeseRules.drl") // ???
<conan_> would make no sense
...
<ge0ffrey> conan_: ... you agree that kieResources.newClassPathResource("/org/cheese/myCheeseRules.drl") should work?
<conan_> yes
was (Author: ge0ffrey):
Just double check with Mark, this a bug, not intended design:
<conan_> kieResources.newClassPathResource("src/main/resource/xxx/org/cheese/myCheeseRules.drl") // ???
<conan_> would make no sense
...
<ge0ffrey> conan_: ... you agree that kieResources.newClassPathResource("/org/cheese/myCheeseRules.drl") should work?
<conan_> yes
> kieResources.newClassPathResource() violates the Class.getResource() conventions
> --------------------------------------------------------------------------------
>
> Key: DROOLS-184
> URL: https://issues.jboss.org/browse/DROOLS-184
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Beta4
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
>
> Suppose I have a jar like this:
> {code}
> cheeseProject-1.0.0.jar
> /org/cheese/MyCheeseApp.class
> /org/cheese/myCheeseRules.drl
> {code}
> There are 2 ways in plain old Java, to get that drl classpath resource:
> {code}
> getClass().getResource("/org/cheese/myCheeseRules.drl") // OK
> getClass().getResource("myCheeseRules.drl") // OK
> {code}
> The KnowledgeBase's classpath resource creation expected similar parameters.
> In KieBase I expected it to work in the same way:
> {code}
> kieResources.newClassPathResource("/org/cheese/myCheeseRules.drl") // FAILS
> kieResources.newClassPathResource("myCheeseRules.drl", MyCheeseApp.class) // FAILS
> {code}
> Instead it expects something like this:
> {code}
> kieResources.newClassPathResource("src/main/resource/xxx/org/cheese/myCheeseRules.drl") // ???
> {code}
> That's not compatible with the JDK definition of a classpath resource, and therefore shouldn't be called newClassPathResource(...). And I 'd like to be able to use the real newClassPathResource() variation.
--
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
[JBoss JIRA] (DROOLS-184) kieResources.newClassPathResource() violates the Class.getResource() conventions
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-184?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-184:
-----------------------------------------
Just double check with Mark, this a bug, not intended design:
<conan_> kieResources.newClassPathResource("src/main/resource/xxx/org/cheese/myCheeseRules.drl") // ???
<conan_> would make no sense
...
<ge0ffrey> conan_: ... you agree that kieResources.newClassPathResource("/org/cheese/myCheeseRules.drl") should work?
<conan_> yes
> kieResources.newClassPathResource() violates the Class.getResource() conventions
> --------------------------------------------------------------------------------
>
> Key: DROOLS-184
> URL: https://issues.jboss.org/browse/DROOLS-184
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Beta4
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
>
> Suppose I have a jar like this:
> {code}
> cheeseProject-1.0.0.jar
> /org/cheese/MyCheeseApp.class
> /org/cheese/myCheeseRules.drl
> {code}
> There are 2 ways in plain old Java, to get that drl classpath resource:
> {code}
> getClass().getResource("/org/cheese/myCheeseRules.drl") // OK
> getClass().getResource("myCheeseRules.drl") // OK
> {code}
> The KnowledgeBase's classpath resource creation expected similar parameters.
> In KieBase I expected it to work in the same way:
> {code}
> kieResources.newClassPathResource("/org/cheese/myCheeseRules.drl") // FAILS
> kieResources.newClassPathResource("myCheeseRules.drl", MyCheeseApp.class) // FAILS
> {code}
> Instead it expects something like this:
> {code}
> kieResources.newClassPathResource("src/main/resource/xxx/org/cheese/myCheeseRules.drl") // ???
> {code}
> That's not compatible with the JDK definition of a classpath resource, and therefore shouldn't be called newClassPathResource(...). And I 'd like to be able to use the real newClassPathResource() variation.
--
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
[JBoss JIRA] (WFLY-1620) EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1620?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1620:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=980183
> EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-1620
> URL: https://issues.jboss.org/browse/WFLY-1620
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Alpha2
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
>
> If you have this no-interface @Stateless EJB in the module and have a
> beans.xml inside the module jar as well and then have a deployment
> depends on & imports the annotations, and then uses @Inject TestEjb,
> Weld will complain that there are two options an EJB and a ManagedBean
> and it doesn't know which to inject. According to [1] it should only be
> considered a managed bean if "It is not annotated with an EJB
> component-defining annotation or declared as an EJB bean class in
> |ejb-jar.xml|."
> The error:
> WELD-001409 Ambiguous dependencies for type [TestEjb] with qualifiers [@Default] at injection point [[field] @Inject test.webapp.TestService.testEjb].
> Possible dependencies [[Session bean [class test.TestEjb with qualifiers [@Any @Default]; local interfaces are [TestEjb], Managed Bean [class test.TestEjb] with qualifiers [@Any @Default]]]
> @Stateless
> public class TestEjb
> {
> public String hello() {
> return "Hello";
> }
> }
> If I move all of the classes into the test war, then Weld doesn't have
> an issue, so it seems there is some difference when the code is put into
> the modules directory.
> [1] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e792
--
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
[JBoss JIRA] (WFLY-1620) EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-1620?page=com.atlassian.jira.plugin.... ]
Brad Maxwell updated WFLY-1620:
-------------------------------
Workaround Description: Use @EJB instead of @Inject
> EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-1620
> URL: https://issues.jboss.org/browse/WFLY-1620
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0.0.Alpha2
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
>
> If you have this no-interface @Stateless EJB in the module and have a
> beans.xml inside the module jar as well and then have a deployment
> depends on & imports the annotations, and then uses @Inject TestEjb,
> Weld will complain that there are two options an EJB and a ManagedBean
> and it doesn't know which to inject. According to [1] it should only be
> considered a managed bean if "It is not annotated with an EJB
> component-defining annotation or declared as an EJB bean class in
> |ejb-jar.xml|."
> The error:
> WELD-001409 Ambiguous dependencies for type [TestEjb] with qualifiers [@Default] at injection point [[field] @Inject test.webapp.TestService.testEjb].
> Possible dependencies [[Session bean [class test.TestEjb with qualifiers [@Any @Default]; local interfaces are [TestEjb], Managed Bean [class test.TestEjb] with qualifiers [@Any @Default]]]
> @Stateless
> public class TestEjb
> {
> public String hello() {
> return "Hello";
> }
> }
> If I move all of the classes into the test war, then Weld doesn't have
> an issue, so it seems there is some difference when the code is put into
> the modules directory.
> [1] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e792
--
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
[JBoss JIRA] (WFLY-1620) EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-1620:
----------------------------------
Summary: EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
Key: WFLY-1620
URL: https://issues.jboss.org/browse/WFLY-1620
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 8.0.0.Alpha2
Reporter: Brad Maxwell
Assignee: Stuart Douglas
If you have this no-interface @Stateless EJB in the module and have a
beans.xml inside the module jar as well and then have a deployment
depends on & imports the annotations, and then uses @Inject TestEjb,
Weld will complain that there are two options an EJB and a ManagedBean
and it doesn't know which to inject. According to [1] it should only be
considered a managed bean if "It is not annotated with an EJB
component-defining annotation or declared as an EJB bean class in
|ejb-jar.xml|."
The error:
WELD-001409 Ambiguous dependencies for type [TestEjb] with qualifiers [@Default] at injection point [[field] @Inject test.webapp.TestService.testEjb].
Possible dependencies [[Session bean [class test.TestEjb with qualifiers [@Any @Default]; local interfaces are [TestEjb], Managed Bean [class test.TestEjb] with qualifiers [@Any @Default]]]
@Stateless
public class TestEjb
{
public String hello() {
return "Hello";
}
}
If I move all of the classes into the test war, then Weld doesn't have
an issue, so it seems there is some difference when the code is put into
the modules directory.
[1] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e792
--
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
[JBoss JIRA] (WFLY-1617) Upgrade maven-enforcer-plugin for Apache Maven 3.1.x support
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-1617?page=com.atlassian.jira.plugin.... ]
Emmanuel Hugonnet updated WFLY-1617:
------------------------------------
Summary: Upgrade maven-enforcer-plugin for Apache Maven 3.1.x support (was: Upgrade maven-enforcer-plugin for MApache Maven 3.1.x support)
> Upgrade maven-enforcer-plugin for Apache Maven 3.1.x support
> ------------------------------------------------------------
>
> Key: WFLY-1617
> URL: https://issues.jboss.org/browse/WFLY-1617
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Affects Versions: 8.0.0.Alpha3
> Reporter: Emmanuel Hugonnet
> Assignee: Paul Gier
>
> When building wildlfy with Apache Maven 3.1.0-alpha1 it complains on missing classes when using the maven-enforcer-plugin.
> Upgrading the maven-enforcer-plugin to version 1.3 enables the build to run successfully on Apache Maven 3.1.0-alpha1 and 3.0.5.
--
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
[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator
by Sergey Alaev (JIRA)
Sergey Alaev created DROOLS-185:
-----------------------------------
Summary: ClassCastException at ConditionEvaluator
Key: DROOLS-185
URL: https://issues.jboss.org/browse/DROOLS-185
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Reporter: Sergey Alaev
Assignee: Mark Proctor
Stacktrace:
Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
Reason:
ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
Given following:
interface A {
String getString();
}
interface B {
String getString();
}
class X implements B, A {}
class Y implements A{}
rule "test rule"
when:
A(string != null)
then:
end
When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
Quickfix: use following declaration of class X:
class X implements A, B {}
Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.
--
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