[JBoss JIRA] (AS7-3293) root context
by Arron Ferguson (JIRA)
Arron Ferguson created AS7-3293:
-----------------------------------
Summary: root context
Key: AS7-3293
URL: https://issues.jboss.org/browse/AS7-3293
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.0.Final
Environment: Windows 7, 64 bit, JDK/RE 7 (Java(TM) SE Runtime Environment (build 1.7.0-b147))
Reporter: Arron Ferguson
Assignee: Remy Maucherat
Context root of a deployed web app results in an HTTP 404 despite web.xml specifying the correct path to a welcome file, e.g.:
<welcome-file-list>
<welcome-file>/index.html</welcome-file>
</welcome-file-list>
...
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
This will result in:
HTTP Status 404 - /myapp/
for example.
On a side note, I'm using a snapshot (jboss-as-7.1.0.Final-SNAPSHOT) and yet the 404 page is stating at the bottom of the 404 page that it is "JBoss Web/7.0.8.Final". Is this right?
--
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, 3 months
[JBoss JIRA] Created: (AS7-1807) Add support for rebranding jars
by Jason Greene (JIRA)
Add support for rebranding jars
-------------------------------
Key: AS7-1807
URL: https://issues.jboss.org/browse/AS7-1807
Project: Application Server 7
Issue Type: Feature Request
Reporter: Jason Greene
Fix For: 7.1.0.Alpha1
In order to make it easier for multiple products (EAP/SOA-P/etc) to consume the same common AS source code, we need to implement a plugability mechanism that allows version numbers, branding skins/themes, logos, etc to be easily replaced (preferably using a single jar).
The mechanism would involve supplying some kind of an argument to the bootstrap. For example:
java -jar \"$JBOSS_HOME/jboss-modules.jar\" \
<snip>
org.jboss.as.standalone
-Djboss.brand.module=org.jboss.as.project-brand
We would then provide some API to get the module so that it can be used to launch services and/or perform resource loading.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (AS7-3116) implement annotations options when specifying dependencies in jboss-deployment-structure.xml
by Peter Skopek (Created) (JIRA)
implement annotations options when specifying dependencies in jboss-deployment-structure.xml
--------------------------------------------------------------------------------------------
Key: AS7-3116
URL: https://issues.jboss.org/browse/AS7-3116
Project: Application Server 7
Issue Type: Feature Request
Components: Server
Affects Versions: 7.1.0.Beta1b
Reporter: Peter Skopek
Assignee: Jason Greene
Priority: Critical
Fix For: 7.1.0.CR1
Implement annotation option of dependency specification as known in MANIFEST.MF to jboss-deployment-structure.xml.
{noformat}
Dependencies: org.picketlink annotations
{noformat}
I need to specify something like this for PicketLink STS (form of web app with webservices) which has all the classes in static module in $JBOSS_HOME/modules:
{noformat}
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.picketlink" annotations="true">
<imports>
<exclude path="org/picketlink/identity/federation/core/pdp/**"/>
</imports>
</module>
</dependencies>
</deployment>
</jboss-deployment-structure>
{noformat}
When combining MANIFEST.MF approach and jboss-deployment-structure.xml the exclude is taken into account we end up with all endpoints of org.picketlink module instantiated which is of course wrong.
Solution to this problem is necessary for PicketLink STS and PDP being able to deploy and function properly.
To be able to try this picketlink resources need to be jandexed. See attached temporary patch.
--
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, 3 months
[JBoss JIRA] (AS7-3284) LegacyGlobalConfigurationAdapter should use externalizer ids from config
by Tristan Tarrant (JIRA)
Tristan Tarrant created AS7-3284:
------------------------------------
Summary: LegacyGlobalConfigurationAdapter should use externalizer ids from config
Key: AS7-3284
URL: https://issues.jboss.org/browse/AS7-3284
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Environment: EDG
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 7.1.0.Final
The LegacyGlobalConfigurationAdapter.adapt() method copies configuration from the legacy Infinispan GlobalConfiguration to the new style GlobalConfiguration. In doing so it attempts to add AdvancedExternalizers as-is, but this causes an NPE when the externalizer has not overridden the AbstractExternalizer.getId() method (which returns null) which is what happens for Externalizers added during ModuleLifecycles (e.g. the server externalizers)
--
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, 3 months
[JBoss JIRA] (JGRP-1412) Rsp: don't null retval on suspect()
by Bela Ban (JIRA)
Bela Ban created JGRP-1412:
------------------------------
Summary: Rsp: don't null retval on suspect()
Key: JGRP-1412
URL: https://issues.jboss.org/browse/JGRP-1412
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.0.3, 3.1
When a valid response 22 has been received from P, then Rsp.received=true and Rsp.retval=22. However, when P is suspected *before* the call returns, then Rsp.retval=null, Rsp.suspected=true and Rsp.received=false
However, maybe we don't care that P was suspected *after* we received a valid response from it !
Therefore, we should leave retval=22 and received=true.
If we get retval=22, received=true and suspected=true, then we know that we got a valid response from P, and that P was suspected later, but before the call completed.
--
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, 3 months