December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5605) Make RestEasy modules public

by Bill Burke (JIRA)

[ https://issues.jboss.org/browse/AS7-5605?page=com.atlassian.jira.plugin.s... ] Bill Burke commented on AS7-5605: --------------------------------- non of resteasy modules should have jboss.api=private > Make RestEasy modules public > ---------------------------- > > Key: AS7-5605 > URL: https://issues.jboss.org/browse/AS7-5605 > Project: Application Server 7 > Issue Type: Feature Request > Components: REST > Affects Versions: 7.1.2.Final (EAP), 7.2.0.Alpha1 > Reporter: Ondrej Zizka > Assignee: Shelly McGowan > Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) > > > The RestEasy modules are all jboss:api="private". > This blocks many use cases - not only RestEasy's annotations, but different providers as well (e.g. Jackson's @JsonIgnore). -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6202) Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6202?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6202: --------------------------------------- The deployment shouldn't be triggering OSGi at all. AIUI, it's a trivial war that has nothing but an index.html. > Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi > --------------------------------------------------------------- > > Key: AS7-6202 > URL: https://issues.jboss.org/browse/AS7-6202 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP) > Reporter: Kabir Khan > Assignee: Thomas Diesler > Attachments: domain.xml, host.xml > > > I noticed this when working on the mixed-domain tests. The attached domain.xml and host.xml contain adjustments for the older slave to work (replacing the MERGE3 jgroups protocol with MERGE2, since 7.1.x does not have that version), and makes all its servers auto-start="false". > To reproduce, start up a DC built from master using those files. Then start up a slave HC built from 7.1.2.Final or 7.1.3.Final using a command like: > ./build/target/jboss-as-7.1.3.Final/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=19999 > Now in CLI: > {code} > [domain@localhost:9999 /] /deployment=test.war:add(content=[{"url" => "file:/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war"}] > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > [domain@localhost:9999 /] /deployment=test.war:remove [domain@localhost:9999 /] /server-group=main-server-group/deployment=test.war:add(enabled=true) > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.", > "rolled-back" => true, > "server-groups" => {"main-server-group" => {"host" => {"kabirs-macbook-pro.local" => {"server-one" => {"response" => { > "outcome" => "failed", > "result" => undefined, > "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]}, > "rolled-back" => true > }}}}}} > } > {code} > The console log for the slave shows > {code} > [Server:server-one] 17:21:22,201 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "test.war" > [Server:server-one] 17:21:22,556 INFO [org.jboss.web] (MSC service thread 1-7) JBAS018210: Registering web context: /test > [Server:server-one] 17:21:22,771 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS015870: Deploy of deployment "test.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]} > [Server:server-one] 17:21:22,814 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test.war in 42ms > {code} > The deployment is very simple, and just contains an html file: > {code} > $unzip -l testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war > Archive: testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war > Length Date Time Name > -------- ---- ---- ---- > 210 12-17-12 16:34 index.html > -------- ------- > 210 1 file > {code} -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6211) JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-6211?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-6211: ------------------------------------- This is a cosmetic issue unless the package versions, which are the ones that matter, are incorrect. What Bundle-Version(s) would you expect? > JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1 > -------------------------------------------------------- > > Key: AS7-6211 > URL: https://issues.jboss.org/browse/AS7-6211 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.2.0.Alpha1 > Environment: Windows 7 > Reporter: jarkko rantavuori > Assignee: Thomas Diesler > > JBoss internal OSGi bundles seem to always report bundle version as 0.0.0. Examples from the admin console: > javax.annotation.api:0.0.0 > javax.ejb.api:0.0.0 > javax.interceptor.api:0.0.0 > javax.jms.api:0.0.0 > javax.jws.api:0.0.0 > javax.management.j2ee.api:0.0.0 > javax.persistence.api:0.0.0 > javax.servlet.api:0.0.0 > javax.transaction.api:0.0.0 > javax.ws.rs.api:0.0.0 > javax.xml.bind.api:0.0.0 > javax.xml.ws.api:0.0.0 > org.jboss.as.osgi.http:0.0.0 -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1802) Sending MapMessage with large String value is broken

by Jess Sightler (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1802?page=com.atlassian.jira.... ] Jess Sightler commented on JBMESSAGING-1802: -------------------------------------------- Hi Justin, The comment itself essentially describes the bug, IMO. It's described as for "performance reasons", but I don't see how that could apply to only StreamMessage. Why would we support writeObject for an ObjectMessage (containing a String) of >65535, but not for a StreamMessage of the same? Performance concerns and considerations would be the same for both of those cases, IMO. I've tried this with HornetQ, and large messages are accepted with StreamMessage. I believe that competing products do as well (this came up in a recent WebLogic migration). Isn't the fix fairly straightforward anyway (pass the longStrings boolean all the way down)? Or is there more here that I'm not seeing? > Sending MapMessage with large String value is broken > ---------------------------------------------------- > > Key: JBMESSAGING-1802 > URL: https://issues.jboss.org/browse/JBMESSAGING-1802 > Project: JBoss Messaging > Issue Type: Feature Request > Affects Versions: 1.4.0.SP3.CP10, 1.4.6.GA > Reporter: Justin Bertram > Assignee: Yong Hao Gao > Fix For: 1.4.8.SP10 > > > Sending a javax.jms.MapMessage that has a String value >= 65536 characters fails. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (JBBUILD-701) Configure jboss-parent to deploy full project sources as part of each release

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/JBBUILD-701?page=com.atlassian.jira.plugi... ] Paul Gier closed JBBUILD-701. ----------------------------- Resolution: Done Added the apache source release configuration to the jboss release profile. https://github.com/jboss/jboss-parent-pom/commit/75865c127167ebb97703343a... > Configure jboss-parent to deploy full project sources as part of each release > ----------------------------------------------------------------------------- > > Key: JBBUILD-701 > URL: https://issues.jboss.org/browse/JBBUILD-701 > Project: JBoss Build System > Issue Type: Enhancement > Components: JBoss Parent POM > Reporter: Paul Gier > Assignee: Paul Gier > Fix For: JBoss Parent POM - 10 > > > For each JBoss project release, the full source zip should be deployed along with the other artifacts. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6211) JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1

by jarkko rantavuori (JIRA)

[ https://issues.jboss.org/browse/AS7-6211?page=com.atlassian.jira.plugin.s... ] jarkko rantavuori updated AS7-6211: ----------------------------------- Steps to Reproduce: - download and unzip 7.2 snapshot from https://ci.jboss.org/jenkins/job/JBoss-AS-7.x-latest/lastSuccessfulBuild/... - add an admin user with bin\add-user - start the server with bin\standalone - view the admin console at http://localhost:9990/console/App.html#osgi-runtime, logging in with admin user was: - download and unzip 7.2 snapshot - add an admin user with bin\add-user - start the server with bin\standalone - view the admin console at http://localhost:9990/console/App.html#osgi-runtime, logging in with admin user > JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1 > -------------------------------------------------------- > > Key: AS7-6211 > URL: https://issues.jboss.org/browse/AS7-6211 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.2.0.Alpha1 > Environment: Windows 7 > Reporter: jarkko rantavuori > Assignee: Thomas Diesler > > JBoss internal OSGi bundles seem to always report bundle version as 0.0.0. Examples from the admin console: > javax.annotation.api:0.0.0 > javax.ejb.api:0.0.0 > javax.interceptor.api:0.0.0 > javax.jms.api:0.0.0 > javax.jws.api:0.0.0 > javax.management.j2ee.api:0.0.0 > javax.persistence.api:0.0.0 > javax.servlet.api:0.0.0 > javax.transaction.api:0.0.0 > javax.ws.rs.api:0.0.0 > javax.xml.bind.api:0.0.0 > javax.xml.ws.api:0.0.0 > org.jboss.as.osgi.http:0.0.0 -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6211) JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1

by jarkko rantavuori (JIRA)

[ https://issues.jboss.org/browse/AS7-6211?page=com.atlassian.jira.plugin.s... ] jarkko rantavuori updated AS7-6211: ----------------------------------- Steps to Reproduce: - download and unzip 7.2 snapshot - add an admin user with bin\add-user - start the server with bin\standalone - view the admin console at http://localhost:9990/console/App.html#osgi-runtime, logging in with admin user was: - download and unzip 7.2 snapshot - add an admin user - start it up - view the admin console at http://localhost:9990/console/App.html#osgi-runtime, logging in with admin user > JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1 > -------------------------------------------------------- > > Key: AS7-6211 > URL: https://issues.jboss.org/browse/AS7-6211 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.2.0.Alpha1 > Environment: Windows 7 > Reporter: jarkko rantavuori > Assignee: Thomas Diesler > > JBoss internal OSGi bundles seem to always report bundle version as 0.0.0. Examples from the admin console: > javax.annotation.api:0.0.0 > javax.ejb.api:0.0.0 > javax.interceptor.api:0.0.0 > javax.jms.api:0.0.0 > javax.jws.api:0.0.0 > javax.management.j2ee.api:0.0.0 > javax.persistence.api:0.0.0 > javax.servlet.api:0.0.0 > javax.transaction.api:0.0.0 > javax.ws.rs.api:0.0.0 > javax.xml.bind.api:0.0.0 > javax.xml.ws.api:0.0.0 > org.jboss.as.osgi.http:0.0.0 -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-6211) JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1

by jarkko rantavuori (JIRA)

jarkko rantavuori created AS7-6211: -------------------------------------- Summary: JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1 Key: AS7-6211 URL: https://issues.jboss.org/browse/AS7-6211 Project: Application Server 7 Issue Type: Bug Components: OSGi Affects Versions: 7.2.0.Alpha1 Environment: Windows 7 Reporter: jarkko rantavuori Assignee: Thomas Diesler JBoss internal OSGi bundles seem to always report bundle version as 0.0.0. Examples from the admin console: javax.annotation.api:0.0.0 javax.ejb.api:0.0.0 javax.interceptor.api:0.0.0 javax.jms.api:0.0.0 javax.jws.api:0.0.0 javax.management.j2ee.api:0.0.0 javax.persistence.api:0.0.0 javax.servlet.api:0.0.0 javax.transaction.api:0.0.0 javax.ws.rs.api:0.0.0 javax.xml.bind.api:0.0.0 javax.xml.ws.api:0.0.0 org.jboss.as.osgi.http:0.0.0 -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-4917) paths need to allow expressions in its 'path' attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-4917?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-4917: ---------------------------------- Parent: AS7-6120 Issue Type: Sub-task (was: Feature Request) > paths need to allow expressions in its 'path' attribute > ------------------------------------------------------- > > Key: AS7-4917 > URL: https://issues.jboss.org/browse/AS7-4917 > Project: Application Server 7 > Issue Type: Sub-task > Components: Logging > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > Fix For: 7.2.0.Alpha1 > > > The "paths" section should allow expressions for "path" elements > Rationale is the fact that customers often want the log files to be send to another directory "outside" of the JBoss directory. > <periodic-rotating-file-handler name="FILE"> > ... > <file relative-to="jboss.server.log.dir" path="server.log"/> > You can change the above and hardcode to : <file path="/logs/jboss/server.log"/> > but that means that as soon as you have two servers on the same machine, using the same profile, they will write to a single logfile. > The "file"s "path" attribute does not allow expressions; this RFE is however not for this attribute. > As relative-to="jboss.server.log.dir" can use self-defined names paths, we looked at the "paths" section. > <paths> > <path name="my.log" path="/logs/jboss/${my.system.propery}"/> > </paths> > but as it turns out, the "path" attribute of the "path" tag also does not allow expressions, and the above entry fails. > Hence: please allow the "path" attribute of the "path" tag to allow expressions so that the above "paths" example works. > Note that we consider this "Major" as customer do/want this functionality often. -- 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

12 years

1
0
0 / 0

[JBoss JIRA] (AS7-4917) paths need to allow expressions in its 'path' attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-4917?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reopened AS7-4917: ----------------------------------- Assignee: Brian Stansberry (was: Jeff Mesnil) Re-opening as I'm making some more tweaks. > paths need to allow expressions in its 'path' attribute > ------------------------------------------------------- > > Key: AS7-4917 > URL: https://issues.jboss.org/browse/AS7-4917 > Project: Application Server 7 > Issue Type: Feature Request > Components: Logging > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > Fix For: 7.2.0.Alpha1 > > > The "paths" section should allow expressions for "path" elements > Rationale is the fact that customers often want the log files to be send to another directory "outside" of the JBoss directory. > <periodic-rotating-file-handler name="FILE"> > ... > <file relative-to="jboss.server.log.dir" path="server.log"/> > You can change the above and hardcode to : <file path="/logs/jboss/server.log"/> > but that means that as soon as you have two servers on the same machine, using the same profile, they will write to a single logfile. > The "file"s "path" attribute does not allow expressions; this RFE is however not for this attribute. > As relative-to="jboss.server.log.dir" can use self-defined names paths, we looked at the "paths" section. > <paths> > <path name="my.log" path="/logs/jboss/${my.system.propery}"/> > </paths> > but as it turns out, the "path" attribute of the "path" tag also does not allow expressions, and the above entry fails. > Hence: please allow the "path" attribute of the "path" tag to allow expressions so that the above "paths" example works. > Note that we consider this "Major" as customer do/want this functionality often. -- 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

12 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2012