[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer commented on DROOLS-471:
-----------------------------------------------
I have done it so far.
Removing the deprecated repository I saw that in
droolsjbpm-integration/kie-remote/kie-services-remote/pom.xml
<!-- security -->
<dependency>
<groupId>javax.security</groupId>
<artifactId>jacc</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
replaced by
<!-- security -->
<dependency>
<groupId>org.jboss.spec.javax.security.jacc</groupId>
<artifactId>jboss-jacc-api_1.5_spec</artifactId>
<version>1.0.0.Final</version>
<scope>provided</scope>
</dependency>
AND
kie-wb-distributions/kie-eap-integration/kie-eap-modules/kie-jboss-eap-base-modules/jboss-eap-6.1.1/javax-security-jacc-api-main/pom.xml
<!-- Custom dependencies. -->
<dependency>
<groupId>javax.security</groupId>
<artifactId>jacc</artifactId>
<version>1.0</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>javax.security.jacc</groupId>
<artifactId>javax.security.jacc-api</artifactId>
<version>1.4</version>
<type>jar</type>
</dependency>
replaced by
<dependency>
<groupId>org.jboss.spec.javax.security.jacc</groupId>
<artifactId>jboss-jacc-api_1.5_spec</artifactId>
<version>1.0.0.Final</version>
<type>jar</type>
</dependency>
were the only "old" dependencies.
I have changed this locally and the build worked.
As org.jboss.spec.javax.security.jacc is specified with its version in jboss-integration-platform-parent I think the <version> tag is dispensable too.
I will inform the module owners.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (DROOLS-466) Reading Rules packaged inside jar
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-466?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-466:
---------------------------------------
We'll investigate. Mario is the best person to answer your question, but he's on holiday and he'll be back next Monday
Davide
> Reading Rules packaged inside jar
> ---------------------------------
>
> Key: DROOLS-466
> URL: https://issues.jboss.org/browse/DROOLS-466
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Ashish Nayyar
> Assignee: Mark Proctor
> Labels: drools, drools-compiler
>
> I am working on DROOLS 6.0.1 application. I have my rule files (*.drl) packaged inside a separate project which is included as a jar file as a maven dependency. When I deploy my project, KIEModule is not able to find the rules files (which are packaged inside the jar above). I am not getting an error though but rules are not getting fired.
> If I manually place the rules files under classpath say WEB-INF/rules/*.drl they are detected and rules are executed.
> I was under impression that KIEmodules are auto discovered from anywhere in classpath.
> Any pointers are appreciated. This is general question hence I have not included the comprehensive code files. Everything start working once I place the *.drl files in the classpath (take them outside of jar).
> On Further invstigation by looking into the code, I found that
> addFiles(assets, kBaseModel, kModule);
> Call from "AbstractKieModule" fails and its not able to find the rules packaged inside the JAR file placed under WEB-INF\lib folder. I get this warning message on the console
> 08:40:02,113 WARN [org.drools.compiler.kie.builder.impl.AbstractKieModule] (ServerService Thread Pool -- 55) No files found for KieBase kie-base-old, searching folder \Apps\jboss-eap-6.1\standalone\deployments\Application.war
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-3309) Update HAL to 2.2.4.Final
by Harald Pehl (JIRA)
Harald Pehl created WFLY-3309:
---------------------------------
Summary: Update HAL to 2.2.4.Final
Key: WFLY-3309
URL: https://issues.jboss.org/browse/WFLY-3309
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Web Console
Reporter: Harald Pehl
Assignee: Harald Pehl
Fix For: 8.1.0.Final
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (DROOLS-466) Reading Rules packaged inside jar
by Ashish Nayyar (JIRA)
[ https://issues.jboss.org/browse/DROOLS-466?page=com.atlassian.jira.plugin... ]
Ashish Nayyar commented on DROOLS-466:
--------------------------------------
Experts,
Please reply.
> Reading Rules packaged inside jar
> ---------------------------------
>
> Key: DROOLS-466
> URL: https://issues.jboss.org/browse/DROOLS-466
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Ashish Nayyar
> Assignee: Mark Proctor
> Labels: drools, drools-compiler
>
> I am working on DROOLS 6.0.1 application. I have my rule files (*.drl) packaged inside a separate project which is included as a jar file as a maven dependency. When I deploy my project, KIEModule is not able to find the rules files (which are packaged inside the jar above). I am not getting an error though but rules are not getting fired.
> If I manually place the rules files under classpath say WEB-INF/rules/*.drl they are detected and rules are executed.
> I was under impression that KIEmodules are auto discovered from anywhere in classpath.
> Any pointers are appreciated. This is general question hence I have not included the comprehensive code files. Everything start working once I place the *.drl files in the classpath (take them outside of jar).
> On Further invstigation by looking into the code, I found that
> addFiles(assets, kBaseModel, kModule);
> Call from "AbstractKieModule" fails and its not able to find the rules packaged inside the JAR file placed under WEB-INF\lib folder. I get this warning message on the console
> 08:40:02,113 WARN [org.drools.compiler.kie.builder.impl.AbstractKieModule] (ServerService Thread Pool -- 55) No files found for KieBase kie-base-old, searching folder \Apps\jboss-eap-6.1\standalone\deployments\Application.war
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-1465) Composite operations failing with incorrect description
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1465?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-1465.
-------------------------------
Resolution: Out of Date
This no longer seems to be an issue.
> Composite operations failing with incorrect description
> -------------------------------------------------------
>
> Key: WFLY-1465
> URL: https://issues.jboss.org/browse/WFLY-1465
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: configure-logging.cli
>
>
> Running the attached script will fail with the message:
> {code}
> #1 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_WARN:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.warn.log", "relative-to"=>"jboss.server.log.dir"})
> #2 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_ERROR:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.error.log", "relative-to"=>"jboss.server.log.dir"})
> #3 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_INFO:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.info.log", "relative-to"=>"jboss.server.log.dir"})
> #4 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_DEBUG:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.debug.log", "relative-to"=>"jboss.server.log.dir"})
> #5 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_TRACE:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.trace.log", "relative-to"=>"jboss.server.log.dir"})
> #6 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_FATAL:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.fatal.log", "relative-to"=>"jboss.server.log.dir"})
> #7 /subsystem=logging/async-handler=WARN_QS_ASYNC:add(level=WARN,queue-length=1024,overflow-action=BLOCK,subhandlers=["FILE_QS_WARN"])
> #8 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:add(level=TRACE)
> #9 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="WARN_QS_ASYNC")
> #10 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_ERROR")
> #11 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_INFO")
> #12 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_DEBUG")
> #13 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_TRACE")
> #14 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_FATAL")
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-9" => "JBAS011536: Handler FILE_QS_FATAL is already assigned."}}
> {code}
> The first issue is that it shouldn't be failing. The second issue is the handler name that failed, is not the same handler that's on the step.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear but doesn't deploy contained ejb module
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-52?page=com.atlassian.jira.plugin.... ]
James Perkins closed JBASMP-52.
-------------------------------
Resolution: Rejected
This should be working, please re-open if this is still an issue.
> jboss-as:deploy deploys ear but doesn't deploy contained ejb module
> -------------------------------------------------------------------
>
> Key: JBASMP-52
> URL: https://issues.jboss.org/browse/JBASMP-52
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.4.Final
> Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
> Reporter: Matías Blasi
> Assignee: James Perkins
>
> I have a simple ear application (build with maven-ear-plugin).
> This application contains just a persistence-unit definition (persistence.xml) and a ejb-module.
> The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin.
> The ear file is correctly built:
> myapp.ear
> |
> + META-INF/application.xml
> + lib/allmylibs.jar
> + myejb.jar
> When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command.
> Finally, an ear file is present under $JBOSS_HOME/standalone/data/content
> The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed)
> Nothing found in google! :(
> I tried with all the plugin version from 7.1.1 to 7.4.
> Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work.
> Regards,
> Matías.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-1037) Add log4j2 support for WildFly
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1037?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-1037:
--------------------------------
Summary: Add log4j2 support for WildFly (was: JBoss AS7 and Log4j2)
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFLY-1037
> URL: https://issues.jboss.org/browse/WFLY-1037
> Project: WildFly
> Issue Type: Clarification
> Security Level: Public(Everyone can see)
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-1037) JBoss AS7 and Log4j2
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1037?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-1037:
--------------------------------
Priority: Optional (was: Major)
> JBoss AS7 and Log4j2
> --------------------
>
> Key: WFLY-1037
> URL: https://issues.jboss.org/browse/WFLY-1037
> Project: WildFly
> Issue Type: Clarification
> Security Level: Public(Everyone can see)
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-3038) BridgeLogger implementation of Logger does not support Level.OFF or null as parameter values for setLevel method
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3038?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-3038.
-------------------------------
Resolution: Out of Date
The {{BridgeLogger}} is no longer use. If this is still an issue please reopen.
> BridgeLogger implementation of Logger does not support Level.OFF or null as parameter values for setLevel method
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3038
> URL: https://issues.jboss.org/browse/WFLY-3038
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: Antonio Montanana
> Assignee: James Perkins
> Labels: jboss
>
> Deploying our application on the JBoss 6.0.0 application server we encounter the following NullPointerException (NPE) also logged in the
> log\server.log file:
> 2011-03-17 12:52:18,269 ERROR
> [filenet_error.engine.com.filenet.engine.tasks.TaskManager]
> (TaskManager$RootTask_RootTask_ScheduledPoolExecutor_9)
> TaskManager$RootTask:RootTask running with error , with message null:
> java.lang.NullPointerException
> at org.jboss.logmanager.log4j.LevelMapping.getLevelFor(LevelMapping.java:65) [:6.0.0.Final]
> at org.jboss.logmanager.log4j.BridgeLogger.setPriority(BridgeLogger.java:199) [:6.0.0.Final]
> at org.jboss.logmanager.log4j.BridgeLogger.setLevel(BridgeLogger.java:194) [:6.0.0.Final]
> at com.filenet.engine.util.Logger.removeTraceLoggerLevel(Logger.java:377)
> ...
> The com.filenet.engine.util.Logger.removeTraceLoggerLevel method executes the following two lines of code:
> org.apache.log4j.Logger traceLogger = getLog4JTraceLogger(subsystem, traceFlag);
> traceLogger.setLevel(null);
> Note the setLevel method is passing in a null parameter value (supported by org.apache.log4j.Logger.setLevel) to remove the specified logging level. We've verified that the JBoss LevelMapping.getLevelFor method throws the NPE as a result of the null parameter value passed into setLevel (changing the parameter value to another level (e.g. Level.DEBUG) eliminates the exception). The setLevel(null) code executed with no exceptions in JBoss 5.1.0 and earlier versions of the server and is supported by org.apache.log4j.Logger.setLevel.
> It appears that the logging mechanism has changed significantly in JBoss 6.0, there is now a BridgeLogger class that extends the
> org.apache.log4j.Logger class providing the implementation of the setLevel method. That implementation appears to have omitted
> support for "null" as a parameter value and causes the NPE. Further testing indicates that the Level.OFF value is also not supported either - leaving no way to remove the logging level.
> We would like to see support for "null" and Level.OFF added to the BridgeLogger extension of Logger.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months