[JBoss JIRA] (WFLY-670) Using "attribute" tag causes injection of null values
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-670?page=com.atlassian.jira.plugin.s... ]
Kabir Khan commented on WFLY-670:
---------------------------------
It is correct that the JMX spec allows you to put in checks. However, the jboss-service.xml configuration from our SAR format is an extension to the JMX spec. My memory is rusty, but I am 99% sure that the JMX spec itself does not contain any configuration, injection and dependency mechanisms, which is why SAR was invented at JBoss to get around this. This was important since we used the JMX microcontroller based on the SAR format as our mechanism to wire services together since at least JBoss 4 (and pretty sure 3, and perhaps even earlier). So this null on stop/uninjection has always happened using our mechanism for attributes that were set via a jboss-service.xml.
So I would say that although this example does not violate the spec, it is a user error not following the rules for something configured via jboss-service.xml. A few suggestions to get around this:
* Remove the null check
* Provide an alternative setter which does not check for null
* Probably the best: Extend ServiceMBeanSupport, then change the setter to only perform this check if in STARTED state, e.g.
{code}
public class Test extends ServiceMBeanSupport implements TestMBean {
private String text;
public String getText() {
return text;
}
public void setText(String text) {
if (getState() == STARTED && text == null) {
throw new NullPointerException("Parameter can not be null");
}
this.text = text;
}
}
{code}
I don’t remember if ServiceMBeanSupport implementing ServiceMBean is enough, or if you also need to make your TestMBean interface extend ServiceMBean.
> Using "attribute" tag causes injection of null values
> -----------------------------------------------------
>
> Key: WFLY-670
> URL: https://issues.jboss.org/browse/WFLY-670
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Reporter: Anders Welen
> Assignee: Tomasz Adamski
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> Using "attribute" tag in "jboss-service.xml" in a SAR archive causes injection of null values. Even if your code can handle this it makes it impossible to use primitive datatypes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rafael Benevides edited comment on WFLY-4171 at 12/18/14 6:48 AM:
------------------------------------------------------------------
I'll start this Jira Tomorrow (Friday) or Monday - I have another issue on DS to finish today before its release on weekend - and I believe that it will take one or two days to conclude it. So until the end of 23th I can have this done. Does that date satisfies the schedule ? Otherwise I can do that at the weekend.
was (Author: rafabene):
I'll start this Jira Tomorrow (Friday) or Monday - I have another issue on DS to finish today before its release on weekend - and I believe that it will take one or two days to conclude it. So until the end of 23th I can have this done.
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (DROOLS-667) Profile why day.index is so much slower than day.getIndex()
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-667?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-667:
------------------------------------
Sorry Geoffrey, I think there's a misunderstanding.
I wrote that I cannot reproduce any relevant performance difference on my machine using the TTP not my microbenchmark.
> Profile why day.index is so much slower than day.getIndex()
> -----------------------------------------------------------
>
> Key: DROOLS-667
> URL: https://issues.jboss.org/browse/DROOLS-667
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR3
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> day.index is 3 times slower than day.getIndex() (and it's gets more as the dataset grows)
> As discussed with Mario. Rough benchmark speeds here:
> https://gist.github.com/ge0ffrey/7662856f357dbec7f7ec
> Reproduce recipe
> - git clone optaplanner
> - Run TravelingTournamentApp, load dataset bra24, solve it for about 30 seconds.
> - Open travelingTournamentScoreRules.drl. Replace all occurrences of "day.getIndex()" with "day.index".
> - Run TravelingTournamentApp again, load dataset bra24, solve it for about 30 seconds again.
> - Compare the last log message of both runs: look for average calculate count per second (x). Higher is faster. For bra24, day.getIndex() is 3 times faster than day.index.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rafael Benevides commented on WFLY-4171:
----------------------------------------
I'll start this Jira Tomorrow (Friday) or Monday - I have another issue on DS to finish today before its release on weekend - and I believe that it will take one or two days to conclude it. So until the end of 23th I can have this done.
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (DROOLS-476) NPE when MVEL parses arithmetic expression
by r1 b2 (JIRA)
[ https://issues.jboss.org/browse/DROOLS-476?page=com.atlassian.jira.plugin... ]
r1 b2 commented on DROOLS-476:
------------------------------
Hi, this bug is still present, any change it gets resolved soon ?
> NPE when MVEL parses arithmetic expression
> ------------------------------------------
>
> Key: DROOLS-476
> URL: https://issues.jboss.org/browse/DROOLS-476
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: sun JDK 1.6;
> Drools 5.5.0Final
> Reporter: Hassler Jean-Christian
> Assignee: Mark Proctor
> Labels: mvel, parsing
>
> When user write computations with MVEL, mvel throw the error {color:red}[Error: not a statement, or badly formed structure] {color}at parsing time.
> If you add parenthesis, parsing is OK.
> The issue can be reproduced directly with the lastest MVEL version.
> As you can see in the test below, same expression with parenthesis is OK. Debugging into mvel engine shows that there some nullPointerException in the bad case.
> This issue was reproduced with the MVEL version embedded inside Drools 5.5.0Final and also with MVEL version 2.1.9.Final.
> {code:java}
> public class MvelTest {
> public void test(){
>
> String expressionThatDoesNotWork = "5 + 1/10 * (VAR - 5)"; // !!! mvel cannot parse this expression
> String expressionThatWorks = "5 + (1/10) * (VAR - 5)"; //with additionnal parenthesis it's OK
>
> Serializable parsingResultOK = MVEL.compileExpression(expressionThatWorks); //this works seamlessly
> System.out.println(parsingResultOK); //=> (Literal<5> + (Literal<0.1> * (VAR - Literal<5>)))
>
> Serializable failedResult = MVEL.compileExpression(expressionThatDoesNotWork); // !!! this throws NullPointerException in MVEL engine
>
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4185) Using annotated servlet listeners from modules
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-4185?page=com.atlassian.jira.plugin.... ]
Pedro Igor commented on WFLY-4185:
----------------------------------
Using latest build from upstream/6.x.
> Using annotated servlet listeners from modules
> ----------------------------------------------
>
> Key: WFLY-4185
> URL: https://issues.jboss.org/browse/WFLY-4185
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> PicketLink provides support for Http Security. Basically, it consists of an API to define security policies to the paths or resources of an application and a security filter (servlet filter) that is responsible to enforce those policies for every single request.
> The security filter is installed from a specific ServletContextListener (org.picketlink.http.internal.PicketLinkServletContextListener) that checks if the application has defined any security policy in order to decide if the filter must be installed or not.
> PicketLink also defines a ServletRequestListener (org.picketlink.http.internal.HttpServletRequestListener) that is used to produce a decorated HttpServletRequest instance. This decorated instance provides full integration between PL and the HttpServletRequest security methods plus some other goodies for PL users such as URL rewriting, etc.
> Both listeners (servletcontext and request) are CDI beans with injection points and/or producer methods.
> When using PL from modules, the producer method of org.picketlink.http.internal.HttpServletRequestListener#produce is not being recognized. And that makes impossible to use PL from modules.
> The same code works if you use PL jars inside the deployment.
> Another interesting behavior is that EAP and WildFly are behaving differently. In EAP (latest build), the ServletContextListener is only recognized as a CDI bean if you define it in the web.xml. While in WildFly this is not necessary.
> Also, in EAP the producer method of HttpServletRequestListener is properly recognized and everything works fine.
> I've created a branch [1] to test this issue. The test case is {code}org.wildfly.test.integration.security.picketlink.core.http.ServletListenerFromModuleTestCase{code}.
> [1] https://github.com/pedroigor/wildfly/tree/WFLY-4185
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-2518) arquillian - domain container - exception when connecting to existing domain without any servers
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2518?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2518:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1175268|https://bugzilla.redhat.com/show_bug.cgi?id=1175268] from POST to MODIFIED
> arquillian - domain container - exception when connecting to existing domain without any servers
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-2518
> URL: https://issues.jboss.org/browse/WFLY-2518
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Martin Simka
> Assignee: Martin Simka
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> {noformat}
> (E) ManagerProcessing
> (O) LoadableExtensionLoader.load
> (E) ServiceLoader
> (E) ManagerStarted
> (O) ConfigurationRegistrar.loadConfiguration
> (E) ArquillianDescriptor
> (O) ContainerRegistryCreator.createRegistry
> (E) ContainerRegistry
> (O) ProtocolRegistryCreator.createRegistry
> (E) ProtocolRegistry
> (E) BeforeSuite
> (I) TestContextHandler.createSuiteContext
> (O) ContainerEventController.execute
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.setupContainers
> (E) SetupContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.setupContainer
> (E) BeforeSetup
> (E) Container
> (E) AfterSetup
> (O) ClientContainerControllerCreator.createClientSideContainerController
> (E) ContainerController
> (O) ClientDeployerCreator.createClientSideDeployer
> (E) Deployer
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.startSuiteContainers
> (E) StartContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.startContainer
> (E) BeforeStart
> (E) ManagementClient
> (E) ArchiveDeployer
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> java.lang.IllegalArgumentException: null
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:124)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1194)
> at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:116)
> at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:126)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rodney Russ (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rodney Russ commented on WFLY-4171:
-----------------------------------
[~rafabene], do you have any idea on when this can be done? We're trying to plan for our next release and as noted above, JBDS-3275 is dependent on this.
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years