[JBoss JIRA] (JBRULES-3329) Add API to allow globals to be specified for the working memory
by David Glassborow (Created) (JIRA)
Add API to allow globals to be specified for the working memory
---------------------------------------------------------------
Key: JBRULES-3329
URL: https://issues.jboss.org/browse/JBRULES-3329
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Affects Versions: FUTURE
Reporter: David Glassborow
Assignee: Mark Proctor
Provide an API to allow globals to be specified to be inserted into the working memory.
This would allow customisation of things like constraint costs. Although this could be done by non-global facts being inserted, performance would be better using a global rather than requiring an instance fact to be matched.
Discussions with Ge0ffrey on IRC revealed that more than 1 working memory exists, and in fact in future versions supporting multithreading or GAs, they may well be many more than one WM, so we need an API that will inject the global into all instances of the WM, just like the global cost constraint global is.
--
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
14 years, 5 months
[JBoss JIRA] (AS7-3695) Management: infinispan cache-container remove operation does not really remove container
by Dominik Pospisil (JIRA)
Dominik Pospisil created AS7-3695:
-------------------------------------
Summary: Management: infinispan cache-container remove operation does not really remove container
Key: AS7-3695
URL: https://issues.jboss.org/browse/AS7-3695
Project: Application Server 7
Issue Type: Bug
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Paul Ferraro
Management: infinispan cache-container remove operation does not really remove container. Subsequent add operation fails.
Steps to reproduce:
[standalone@localhost:9999 subsystem=infinispan] ./cache-container=test2:add(start="EAGER")
{"outcome" => "success"}
[standalone@localhost:9999 subsystem=infinispan] ./cache-container=test2:remove
{"outcome" => "success"}
[standalone@localhost:9999 subsystem=infinispan] ./cache-container=test2:add(start="EAGER")
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: Service jboss.naming.context.java.jboss.infinispan.container.test2 is already registered",
"rolled-back" => true
}
--
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
14 years, 5 months
[JBoss JIRA] Created: (AS7-1762) rewrite rule doesnt function
by jefimm (JIRA)
rewrite rule doesnt function
----------------------------
Key: AS7-1762
URL: https://issues.jboss.org/browse/AS7-1762
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.0.1.Final
Reporter: jefimm
Assignee: Remy Maucherat
I have tried to add the following configuration to the standalone.xml <virtual-server> node:
<virtual-server name="default-host">
<alias name="localhost"/>
<alias name="example.com"/>
<rewrite pattern="^/helloworld(.*)" substitution="/helloworld/test.jsp"/>
</virtual-server>
and I have deployed the helloworld.war, however the rewrite does not work (I know I can deploy war at the root context I just want to test the rewrite).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] (JBWEB-228) Globally configure an Authenticator Valve for the whole JBoss.
by Mo Zo (JIRA)
Mo Zo created JBWEB-228:
---------------------------
Summary: Globally configure an Authenticator Valve for the whole JBoss.
Key: JBWEB-228
URL: https://issues.jboss.org/browse/JBWEB-228
Project: JBoss Web
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: JBossWeb-7.0.9.GA, JBossWeb-7.0.2.GA, JBossWeb-7.0.1.GA , JBossWeb-7.0.0.GA
Reporter: Mo Zo
Assignee: Remy Maucherat
Please add an option to set and configure an Authenticator (Valve) globally for all applications in a JBoss by using standard JBoss mechanisms like domain.xml, standalone.xml and DMR, so that it would be possible to reference an Authenticator like this:
web.xml
<login-config>
<auth-method>CUSTOM</auth-method>
</login-config>
To achieve this I had to modify:
...\modules\org\jboss\as\web\main\jbossweb-7.0.X.Final.jar\org\apache\catalina\startup\Authenticators.properties
CUSTOM=<full qualified authenticator class name>
which certainly is not a good way.
--
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
14 years, 5 months
[JBoss JIRA] (AS7-3690) standalone-xts.xml fallen out of sync with standalone-full.xml
by Paul Robinson (JIRA)
Paul Robinson created AS7-3690:
----------------------------------
Summary: standalone-xts.xml fallen out of sync with standalone-full.xml
Key: AS7-3690
URL: https://issues.jboss.org/browse/AS7-3690
Project: Application Server 7
Issue Type: Bug
Components: Transactions
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 7.1.0.Final
The only differences between ./build/src/main/resources/docs/examples/configs/standalone-xts.xml and ./build/src/main/resources/standalone/configuration/standalone-full.xml should be as follows:
{code}
34d33
< <extension module="org.jboss.as.xts"/>
379,381d377
< <subsystem xmlns="urn:jboss:domain:xts:1.0">
< <xts-environment url="http://localhost:8080/ws-c11/ActivationService"/>
< </subsystem>
{code}
However, the diff is now as follows:
{code}
diff ./build/src/main/resources/docs/examples/configs/standalone-xts.xml ./build/src/main/resources/standalone/configuration/standalone-full.xml
13a14
> <extension module="org.jboss.as.jaxr"/>
33d33
< <extension module="org.jboss.as.xts"/>
42a43,47
> <security-realm name="ApplicationRealm">
> <authentication>
> <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
> </authentication>
> </security-realm>
100d104
< <pool></pool>
173a178,181
> <subsystem xmlns="urn:jboss:domain:jaxr:1.0">
> <connection-factory jndi-name="java:jboss/jaxr/ConnectionFactory"/>
> <juddi-server publish-url="http://localhost:8080/juddi/publish" query-url="http://localhost:8080/juddi/query"/>
> </subsystem>
199c207
< <subsystem xmlns="urn:jboss:domain:jpa:1.0">
---
> <subsystem xmlns="urn:jboss:domain:jpa:1.0">
241d248
< <!--default for catch all-->
247d253
< <message-counter-history-day-limit>10</message-counter-history-day-limit>
248a255
> <message-counter-history-day-limit>10</message-counter-history-day-limit>
312c319
< <connector name="remoting-connector" socket-binding="remoting"/>
---
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
320c327,335
< <login-module code="UsersRoles" flag="required"/>
---
> <login-module code="Remoting" flag="optional">
> <module-option name="password-stacking" value="useFirstPass"/>
> </login-module>
> <login-module code="RealmUsersRoles" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/application-users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/application-roles.properties"/>
> <module-option name="realm" value="ApplicationRealm"/>
> <module-option name="password-stacking" value="useFirstPass"/>
> </login-module>
363,365d377
< <subsystem xmlns="urn:jboss:domain:xts:1.0">
< <xts-environment url="http://localhost:8080/ws-c11/ActivationService"/>
< </subsystem>
383a396
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>
394d406
<
{code}
--
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
14 years, 5 months
[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Remy Maucherat updated AS7-3607:
--------------------------------
Summary: Native connector shoudl support the java.net.preferIPv4Stack system property (was: IPv6: Incorrect address binding - web subsystem)
Issue Type: Feature Request (was: Bug)
Priority: Major (was: Critical)
Native does not magically care about Java system properties, so unless something specific is done to handle this one, it is not going to change the behavior in any way.
So the Jira is about adding support for the java.net.preferIPv4Stack system property. I don't understand the urgency / panic mode, though. The normal usage should be to set the desired bind address in the configuration, not rely on some automagic behavior.
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
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
14 years, 5 months
[JBoss JIRA] (AS7-3700) jboss-as-arquillian-container-managed 7.0.2.Final ships with jboss-logging 3.0.0.GA, but some of its modules require a higher version: jboss-logging 3.0.1.GA. Same for xnio-api and jbosgi-vfs.
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/AS7-3700?page=com.atlassian.jira.plugin.s... ]
Geoffrey De Smet commented on AS7-3700:
---------------------------------------
Haven't tried 7.1.0.CR1.
Once Paul has applied and released the enforcer plugin with this issue:
http://jira.codehaus.org/browse/MENFORCER-128
it should be easy to confirm in any build, including the 7.1.0.CR1 build.
> jboss-as-arquillian-container-managed 7.0.2.Final ships with jboss-logging 3.0.0.GA, but some of its modules require a higher version: jboss-logging 3.0.1.GA. Same for xnio-api and jbosgi-vfs.
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3700
> URL: https://issues.jboss.org/browse/AS7-3700
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Reporter: Geoffrey De Smet
> Priority: Trivial
>
> The xnio-api is probably the most dangerous one of these 3.
> It ships with xnio-api 3.0.0.Beta2, but some code requires 3.0.0.Beta3.
> {code}
> IncompatibleDependencyOverwrite error for org.jboss.logging:jboss-logging:3.0.0.GA paths to dependency are:
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.sasl:jboss-sasl:1.0.0.Beta2
> +-org.jboss.logging:jboss-logging:3.0.0.GA
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-testenricher-msc:7.0.2.Final
> +-org.jboss.logging:jboss-logging:3.0.1.GA
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.osgi.spi:jbosgi-spi:1.0.28
> +-org.jboss.logging:jboss-logging:3.0.0.Beta3
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-controller-client:7.0.2.Final
> +-org.jboss.as:jboss-as-protocol:7.0.2.Final
> +-org.jboss.logging:jboss-logging:3.0.1.GA
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.osgi.spi:jbosgi-spi:1.0.28
> +-org.jboss.osgi.vfs:jbosgi-vfs:1.0.5
> +-org.jboss.logging:jboss-logging:3.0.0.Beta3
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-controller-client:7.0.2.Final
> +-org.jboss.as:jboss-as-protocol:7.0.2.Final
> +-org.jboss.remoting3:jboss-remoting:3.2.0.Beta2
> +-org.jboss.logging:jboss-logging:3.0.0.Beta5
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-jmx:7.0.2.Final
> +-org.jboss.as:jboss-as-server:7.0.2.Final
> +-org.jboss.as:jboss-as-controller:7.0.2.Final
> +-org.jboss.logging:jboss-logging:3.0.1.GA
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-jmx:7.0.2.Final
> +-org.jboss.as:jboss-as-server:7.0.2.Final
> +-org.jboss.as:jboss-as-domain-http-api:7.0.2.Final
> +-org.jboss.logging:jboss-logging:3.0.1.GA
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-jmx:7.0.2.Final
> +-org.jboss.as:jboss-as-server:7.0.2.Final
> +-org.jboss.as:jboss-as-deployment-repository:7.0.2.Final
> +-org.jboss.logging:jboss-logging:3.0.1.GA
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-jmx:7.0.2.Final
> +-org.jboss.as:jboss-as-server:7.0.2.Final
> +-org.jboss.as:jboss-as-process-controller:7.0.2.Final
> +-org.jboss.logging:jboss-logging:3.0.1.GA
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-protocol-jmx:7.0.2.Final
> +-org.jboss.as:jboss-as-osgi-service:7.0.2.Final
> +-org.jboss.osgi.resolver:jbosgi-resolver-api:1.0.9
> +-org.jboss.osgi.resolver:jbosgi-resolver-metadata:1.0.9
> +-org.jboss.logging:jboss-logging:3.0.0.Beta3
> ,
> IncompatibleDependencyOverwrite error for org.jboss.xnio:xnio-api:3.0.0.Beta2 paths to dependency are:
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-controller-client:7.0.2.Final
> +-org.jboss.as:jboss-as-protocol:7.0.2.Final
> +-org.jboss.remoting3:jboss-remoting:3.2.0.Beta2
> +-org.jboss.xnio:xnio-api:3.0.0.Beta2
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-controller-client:7.0.2.Final
> +-org.jboss.as:jboss-as-protocol:7.0.2.Final
> +-org.jboss.xnio:xnio-nio:3.0.0.Beta3
> +-org.jboss.xnio:xnio-api:3.0.0.Beta3
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.as:jboss-as-jmx:7.0.2.Final
> +-org.jboss.as:jboss-as-server:7.0.2.Final
> +-org.jboss.as:jboss-as-remoting:7.0.2.Final
> +-org.jboss.xnio:xnio-api:3.0.0.Beta3
> ,
> IncompatibleDependencyOverwrite error for org.jboss.osgi.vfs:jbosgi-vfs:1.0.5 paths to dependency are:
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-common:7.0.2.Final
> +-org.jboss.osgi.spi:jbosgi-spi:1.0.28
> +-org.jboss.osgi.vfs:jbosgi-vfs:1.0.5
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-protocol-jmx:7.0.2.Final
> +-org.jboss.as:jboss-as-osgi-service:7.0.2.Final
> +-org.jboss.osgi.vfs:jbosgi-vfs:1.0.6
> and
> +-org.jboss.as:jboss-as-arquillian-container-managed:7.0.2.Final
> +-org.jboss.as:jboss-as-arquillian-protocol-jmx:7.0.2.Final
> +-org.jboss.as:jboss-as-osgi-service:7.0.2.Final
> +-org.jboss.osgi.framework:jbosgi-framework-core:1.0.0.CR8
> +-org.jboss.osgi.vfs:jbosgi-vfs30:1.0.6
> +-org.jboss.osgi.vfs:jbosgi-vfs:1.0.6
> {code}
> Maybe JBoss modules makes this not as bad as it is with normal maven projects.
--
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
14 years, 5 months