[JBoss JIRA] Created: (JBAS-4282) Can't create a root context web app
by Stan Silvert (JIRA)
Can't create a root context web app
-----------------------------------
Key: JBAS-4282
URL: http://jira.jboss.com/jira/browse/JBAS-4282
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.Beta2
Reporter: Stan Silvert
Assigned To: Remy Maucherat
I am unable to deploy a web app as root context using the instructions here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=SetupARootContextApp
One thing that is unclear is if ROOT.war "must" be removed from /deploy. In 4.2, root context web apps do not require removal of ROOT.war. IMHO, this is how it should work. If you deploy a WAR as the root context, it should simply override whatever was there before.
If ROOT.war is removed, 5.0 will allow a root context web app as long as it is deployed from an EAR and specified as such in application.xml. Otherwise, it will fail.
If you choose to deploy a stand-alone WAR and specify it as root context using jboss-web.xml, it will always fail - regardless of whether or not you remove ROOT.war.
I have committed a test for root deployment in both 4.2 and 5.0. The test passes in 4.2, but not in 5.0. You can run it with:
build one-test -Dtest=org.jboss.test.web.test.RootContextUnitTestCase
--
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
18 years
[JBoss JIRA] Created: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin
by Bela Ban (JIRA)
Investigate marshalling format to simplify wireshark / ethereal plugin
-----------------------------------------------------------------------
Key: JGRP-494
URL: http://jira.jboss.com/jira/browse/JGRP-494
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Currently, parsing JGroups network data via wireshark is difficult:
- message lists don't have (a) total number of bytes and (b) bytes/message and
- headers don't have (a) total bytes for all headers and (b) bytes / header
Investigate whether we can change the marshalling format to accommodate the wireshark plugin. This has the nice side effect that the JGroups wire format becomes standardized, ie. each header has the same format. This allows us to display a header even if we don't know how to parse it. In this case, we'd simply display the name and number of bytes.
Caveat: we want to avoid having to make messages bigger when marshalled.
--
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
18 years
[JBoss JIRA] Created: (JBWEB-83) When the native libraries are missing it is not possible to use ajp
by Jean-Frederic Clere (JIRA)
When the native libraries are missing it is not possible to use ajp
-------------------------------------------------------------------
Key: JBWEB-83
URL: http://jira.jboss.com/jira/browse/JBWEB-83
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBoss Web Server 1.0.1 GA
Environment: Any
Reporter: Jean-Frederic Clere
Assigned To: Mladen Turk
When the ./bin/native/libtcnative-1.so or one of the components of Jboss Web native is missing. The ajp connector is defaulted to a http one:
+++
17:37:05,565 ERROR [AprLifecycleListener] The Apache Tomcat Native library that JBoss Web requires (only the HTTP connector will be available) was not found on the java.library.path: /home/jfclere/TMP/jbossweb-1.0.1.GA/bin/native
17:37:05,636 INFO [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
17:37:05,637 INFO [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8009
+++
--
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
18 years
[JBoss JIRA] Created: (JBWEB-66) basic-auth broken
by Mark Stewart (JIRA)
basic-auth broken
-----------------
Key: JBWEB-66
URL: http://jira.jboss.com/jira/browse/JBWEB-66
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBoss Web Server 1.0.0 GA
Environment: Linux
Reporter: Mark Stewart
Assigned To: Mladen Turk
Assuming that Jboss Web is configured identically to the web container in AS, it seems that basic-auth support is broken. That is, the server doesn't send a 401 for protected urls.
Here's the post I made three weeks ago on the Jboss Web Server forum:
"I have a webapp I usually run in JBoss AS that I'm trying to get running under JBossWeb. I've added the same entry to login-module.xml in the default/conf/ directory and a jboss-web.xml file whose <security-domain> tag points at the entry in default/deploy/<my-web-app.war>/WEB-INF. JBossWeb doesn't block the access to the protected pages, however."
This is tested by the J2EE CTS so I guess JBossWeb wasn't tested against it (or the failure was ignored) prior to the GA release.
--
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
18 years
[JBoss JIRA] Created: (JBPORTAL-1152) testsuite problem with sybase
by Prabhat Jha (JIRA)
testsuite problem with sybase
-----------------------------
Key: JBPORTAL-1152
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1152
Project: JBoss Portal
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Prabhat Jha
Assigned To: Roy Russo
During portal testsuite run with sybase database, tables are not getting created successfully. These are two major errors that I see:
1. ERROR [SchemaExport] Unsuccessful: create table jbp_cms_cmsentry (PK int identity not null, FSENTRY_NAME varchar(255) null, FSENTRY_PATH varchar(245) not null, FSENTRY_DATA image nu\ ll, FSENTRY_LASTMOD numeric(19,0) not null, FSENTRY_LENGTH numeric(19,0) not null, primary key (PK))
[junit_] 17:50:33,387 ERROR [SchemaExport] Identity field 'PK' must be a numeric with a scale of 0 and not null allowed.
2. ERROR [SchemaExport] Unsuccessful: create table jbp_cms_version_refs (PK int identity not null, NODE_ID varchar(36) null, REFS_DATA varbinary(100000000) not null, primary key (PK))
[junit_] 17:50:33,413 ERROR [SchemaExport] Length or precision specification 100000000 is not within the range of 1 to 16384.
Assigning it to Roy since you seem to be the most involved with it. ;-)
--
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
18 years
[JBoss JIRA] Created: (JBWEB-75) Contention in ApplicationContext
by Phillip Thurmond (JIRA)
Contention in ApplicationContext
--------------------------------
Key: JBWEB-75
URL: http://jira.jboss.com/jira/browse/JBWEB-75
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss 4.0.5, Linux, Java 5
Reporter: Phillip Thurmond
Assigned To: Mladen Turk
I'm seeing some contention inside Tomcat on ApplicationContext.getAttribute() when I run performance tests using a Seam application. With a load of 200 threads, I often see over 150 "waiting to lock" messages on the attributes object. It looks like this contention has already been fixed in Tomcat 6 using the Java 5 concurrent objects.
I also posted to the Tomcat development list about this issue, but Remy did not want to fix it because he didn't want to introduce any new dependencies into the project. I think this is important to fix if we expect users to deploy Seam on 4.0.5.
Example thread dump:
"http-10.68.0.196-8080-301" daemon prio=1 tid=0x0000002b51e425b0 nid=0x78a5 waiting for monitor entry [0x000000005b86c000..0x000000005b86cdb0]
at org.apache.catalina.core.ApplicationContext.getAttribute(ApplicationContext.java:175)
- waiting to lock <0x0000002aabd633b0> (a java.util.HashMap)
at org.apache.catalina.core.ApplicationContextFacade.getAttribute(ApplicationContextFacade.java:315)
at org.apache.myfaces.context.servlet.ApplicationMap.getAttribute(ApplicationMap.java:41)
at org.apache.myfaces.context.servlet.AbstractAttributeMap.get(AbstractAttributeMap.java:87)
at org.jboss.seam.contexts.FacesApplicationContext.get(FacesApplicationContext.java:47)
at org.jboss.seam.Component.forName(Component.java:1588)
at org.jboss.seam.Component.getInstance(Component.java:1636)
at org.jboss.seam.Component.getInstance(Component.java:1631)
at org.jboss.seam.Component.getInstance(Component.java:1608)
at org.jboss.seam.Component.getInstance(Component.java:1603)
at org.jboss.seam.core.Events.instance(Events.java:158)
at org.jboss.seam.jsf.AbstractSeamPhaseListener.afterPhase(AbstractSeamPhaseListener.java:139)
at org.jboss.seam.jsf.SeamPhaseListener.afterPhase(SeamPhaseListener.java:69)
--
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
18 years