[JBoss JIRA] Created: (JBMESSAGING-804) Provide a clean jboss-messaging-client.jar without containing external dependencies
by Galder Zamarreno (JIRA)
Provide a clean jboss-messaging-client.jar without containing external dependencies
-----------------------------------------------------------------------------------
Key: JBMESSAGING-804
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-804
Project: JBoss Messaging
Issue Type: Feature Request
Components: Build System
Affects Versions: 1.0.1.SP3, 1.2.0.Beta1
Reporter: Galder Zamarreno
Assigned To: Ovidiu Feodorov
Fix For: 1.2.0.Beta2, 1.0.1.SP4
We've installed JBoss messaging instead of JBossMQ and updated our application to connect to this.
We have to include jboss-messaging-client.jar to be able to use it, but now the following problem arises:
jboss-messaging-client.jar has log4j classes in it, which are of an old version. Therefore, our .war
cannot deploy because it uses methods of log4j of the newer version (e.g. Logger.isTraceEnabled()).
To your approach of patching jboss-messaging-client.jar: maybe we'll try it, but I'm afraid it includes
more classes that may clash with our system... What we need is a clean jboss-messaging-client.jar file,
without external dependencies, but I don't want to build it myself as it makes maintaining our JBoss
setup very hard.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBMESSAGING-725) Add a release-admin check that would cleanly stop the installation process if ant version is too old
by Ovidiu Feodorov (JIRA)
Add a release-admin check that would cleanly stop the installation process if ant version is too old
----------------------------------------------------------------------------------------------------
Key: JBMESSAGING-725
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-725
Project: JBoss Messaging
Issue Type: Feature Request
Reporter: Ovidiu Feodorov
Assigned To: Ovidiu Feodorov
Priority: Minor
Fix For: 1.2.0.CR1
... and avoid cryptic failures like this one:
[C:/temp/jboss-messaging-1.2.0.Beta1/util] ant -f release-admin.xml
Buildfile: release-admin.xml
default:
BUILD FAILED
C:\temp\jboss-messaging-1.2.0.Beta1\util\release-admin.xml:36: The following error occurred while ex
ecuting this line:
C:\temp\jboss-messaging-1.2.0.Beta1\util\release-admin.xml:519: Class org.apache.tools.ant.taskdefs.
ConditionTask doesn't support the nested "length" element.
Total time: 1 second
[C:/temp/jboss-messaging-1.2.0.Beta1/util] ant -version
Apache Ant version 1.6.2 compiled on July 16 2004
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBMESSAGING-925) Remove requirement to deploy JBM scoped in JB AS <= 4.2
by Tim Fox (JIRA)
Remove requirement to deploy JBM scoped in JB AS <= 4.2
-------------------------------------------------------
Key: JBMESSAGING-925
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-925
Project: JBoss Messaging
Issue Type: Task
Affects Versions: 1.2.0.GA
Reporter: Tim Fox
Priority: Critical
Fix For: 1.2.0.SP1
Currently JBM needs to be deployed as a scoped deployment in every all the GA releases of JBoss AS.
This causes considerable configuration headaches for users and more than likely acts as a major barrier to adoption of JBM.
We currently scope because we use more recent versions of JBoss Remoting and JBoss AOP than the versions deployed in JBAS.
It appears that, other than JBM, only EJB3 and parts of JBoss WS actually use AOP and remoting so instead of deploying scoped we should first verify whether WS and EJB3 work with the later versions of AOP and remoting, and if not we should patch AOP and remoting to get them to work.
Then we can overwrite the versions of remoting and aop in server/lib in the AS during the JBM install procedure and deploy unscoped - this would be a huge win for the project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBFORUMS-204) building sources
by Luca Stancapiano (JIRA)
building sources
----------------
Key: JBFORUMS-204
URL: http://jira.jboss.com/jira/browse/JBFORUMS-204
Project: JBoss Forums
Issue Type: Bug
Components: Portlet Productization
Affects Versions: 1.0.0 RC
Environment: all
Reporter: Luca Stancapiano
Assigned To: Ryszard Kozmik
Fix For: 1.0.0 GA
hi......I try to build sources of forums applicattion (taken from http://anonsvn.labs.jboss.com/labs/jbossforums/trunk).
Apparently it is ok but when I deploy jboss-forums.ear, I have the error that portal-forums-authz-plugin.sar is lost. Inside jboss-forums.ear infact it is not added. I added in build.xml row 162 of authz-jaae-plugin project theese rows:
<copy todir="${forums.root}/resources/portal-forums-ear">
<fileset dir="${authz-jaae-plugin.lib}" includes="portal-forums-authz-plugin.sar"/>
</copy>
<jar jarfile="${forums.lib}/jboss-forums.ear">
<fileset dir="${forums.root}/resources/portal-forums-ear" includes="**/*"/>
</jar>
so, when target output of forums is executed, portal-forums-authz-plugin.sar is added automatically into jboss-forums.ear
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBPM-928) filter missing in hibernate mapping for ProcessDefinition
by Britt Miner (JIRA)
filter missing in hibernate mapping for ProcessDefinition
---------------------------------------------------------
Key: JBPM-928
URL: http://jira.jboss.com/jira/browse/JBPM-928
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2, jBPM 3.1.2
Reporter: Britt Miner
Assigned To: Tom Baeyens
Symptom: processDefinition.findNode(), getNode(), getNodeList(), and getNodesMap() (basically all node related methods on ProcessDefinition) fail to properly find or return all Nodes when SuperStates are present.
Cause: Hibernate mapping for ProcessDefinition does not recognize that NODEINDEXCOLLECTION_ on the jbpm_node table may have duplicated values per ProcessDefinition (members of a SuperState comprise a separate node collection in this column) and only picks up the last Node with a given NODEINDEXCOLLECTION_ value.
The list-index line is the problem:
<list name="nodes" cascade="all">
<cache usage="nonstrict-read-write"/>
<key column="PROCESSDEFINITION_" />
<list-index column="NODECOLLECTIONINDEX_" />
<one-to-many class="org.jbpm.graph.def.Node" />
</list>
Solution: Perhaps usage of a Set instead of a list would solve the problem (Sets don't use 'list-index'), or a Hibernate Bag collection would allow usage of a List in the object without the requirement of list-index (with an associated performance hit). Or perhaps some type of Hibernate filter could be used.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBBUILD-364) Update wiki page(s) about snapshots and releases.
by Paul Gier (JIRA)
Update wiki page(s) about snapshots and releases.
-------------------------------------------------
Key: JBBUILD-364
URL: http://jira.jboss.com/jira/browse/JBBUILD-364
Project: JBoss Build System
Issue Type: Feature Request
Reporter: Paul Gier
Assigned To: Paul Gier
Fix For: MavenBuild 2.0
Adrian brought up a few things that should be included on the wiki pages about how to release jboss projects.
* the version policy (how do you decide what the next version is)
* move the pom.xml onto the next release/snapshot when finished?
* tagging (how the maven version relates to SVN tags)
* a release cannot depend on snapshots (how to resolve when it does)
* all tests must pass (QA approved release?).
* all JIRA issues should be closed
* JIRA needs updating to move along the released project
* Notifying product support about the new release (where relevant)
* Agreement from project lead
The old wiki pages about releases should also be checked to see what other information should be included.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months