[JBoss JIRA] Created: (JBAS-4253) ServletContext().getRealPath("/") is returning null
by Scott M Stark (JIRA)
ServletContext().getRealPath("/") is returning null
---------------------------------------------------
Key: JBAS-4253
URL: http://jira.jboss.com/jira/browse/JBAS-4253
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Reporter: Scott M Stark
Assigned To: Remy Maucherat
Fix For: JBossAS-5.0.0.Beta2
The following call:
String realPath = getServletContext().getRealPath("/");
is failing due to a null path being returned. I assume this is a vfs integration issue.
<testcase classname="org.jboss.test.web.test.WebIntegrationUnitTestCase" name="testRealPath" time="0.15">
−
<error message="Expected reply code:200, actual=500" type="java.io.IOException">
java.io.IOException: Expected reply code:200, actual=500
at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:137)
at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:108)
at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:96)
at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:82)
at org.jboss.test.web.test.WebIntegrationUnitTestCase.testRealPath(WebIntegrationUnitTestCase.java:67)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
</error>
</testcase>
--
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
17 years, 1 month
[JBoss JIRA] Created: (JBFORUMS-245) implementation for multiple forums
by Luca Stancapiano (JIRA)
implementation for multiple forums
----------------------------------
Key: JBFORUMS-245
URL: http://jira.jboss.com/jira/browse/JBFORUMS-245
Project: JBoss Forums
Issue Type: Patch
Components: Forum Model Layer, Forum Test Suite
Affects Versions: 1.0.1 GA
Environment: eclipse 3.2.2 , jboss as 4.0.5_cp_04, jboss portal taken from http://anonsvn.jboss.org/repos/portal/trunk since 9 jun 2007, jboss forums taken from http://anonsvn.labs.jboss.com/labs/jbossforums/branches/forums101P26 since 23 jun 2007
Reporter: Luca Stancapiano
Assigned To: Ryszard Kozmik
Fix For: 1.0.1 GA
hi....I have a patch to use multiple forums into the portal.... updates are many because I added an argument in several method. The principal update is to add a jbp_forums_instances table that contains
the instance for the forum and a field jbp_id that represents the instance. You can to add a new forum directly by web adding a preference from portlet instances form of portal. The new forum is represented by a foruminstanceid preference. It is a number that identify a forum. If two instances of forum has the same foruminstanceid , then they are equals, while if those preferences are different , then the forums are different and they will get different categories, forums, topics ...etc etc. I describe my update in steps:
STEP 1: DATABASE AND HIBERNATE
1 - added a table called jbp_forums_instances managed through hibernate through interface ForumInstance and class ForumInstanceImpl as for the other tables in the forums
2 - added a field into jbp_forums_categories called jbp_forum_instance_id , that it tie in a one-to-many relation to jbp_forums_instances table and updated Category interface and CategoryImplClass
3 - updated src/resources/setup/setup.sql with the updates over mentioned
4 - updated src/resources/portal-forums-sar/conf/hibernate/setup.txt with the updates over mentioned
5 - updated src/resources/portal-forums-sar/conf/hibernate/hibernate.cfg.xml adding the creation of ForumInstance object into database
STEP 2 - PREFERENCES
1 - updated src/resources/portal-forums-war/WEB-INF/portlet.xml adding foruminstanceid preference to configure through web into portlet instances of portal
STEP 3 - METHODS
1 - updated findTopics, findTopicsHot, ,findTopicsByLatestPosts , findTopicsHottest, findTopicsMostViewed, findPosts, ,findCategories , findCategoriesFetchForums, findForums, createCategory, findLastPostsOfForums, findForumWatchByUser, findForumWatchedByUser, findTopicWatchedByUser, findTopicWatches and findForumWatches methods into src/main/org/jboss/portlet/forums/ForumsModule.java and src/main/org/jboss/portlet/forums/impl/ForumsModuleImpl.java to use forumInstanceId argument
2 - created findForumInstanceById, createForumInstance, removeForumInstance into src/main/org/jboss/portlet/forums/ForumsModule.java and src/main/org/jboss/portlet/forums/impl/ForumsModuleImpl.java to manage ForumInstance objects
STEP 4 - TEST
1 - updated src/main/org/jboss/portlet/test/forums/CategoryModelTestCase.java to use new updates for methods
2 - updated src/main/org/jboss/portlet/test/forums/ForumModelTestCase.java to use new updates for methods
3 - updated src/main/org/jboss/portlet/test/forums/TopicModelTestCase.java to use new updates for methods
4 - updated src/main/org/jboss/portlet/test/forums/PostModelTestCase.java to use new updates for methods
SETP 5 - ACTIONS
1- added getPreferences method into src/main/org/jboss/portlet/forums/ui/FormUtil.java. This method is similar to getPreferences of PortalUtil class but it let to get the preferences also for an anonymous user:
public static String getPreference(String preferenceKey)
{
String preference = null;
Object o = FacesContext.getCurrentInstance().getExternalContext()
.getRequest();
if (o instanceof PortletRequest)
{
PortletRequest request = (PortletRequest) o;
PortletPreferences pp = request.getPreferences();
preference = pp.getValue(preferenceKey, "");
}
return preference;
}
2 - updated all actions and views that need to get foruminstanceid to query and insert forum objects.
Updated actions are:
addCategory, moveCategoryDown and moveCategoryUp methods of src/main/org/jboss/portlet/forums/ui/action/AdminController.java
Updated views are:
getCategories and getForums methods of src/main/org/jboss/portlet/forums/ui/view/ViewAdminPanel.java
execute method of src/main/org/jboss/portlet/forums/ui/view/ViewCategory.java
getCategories method of src/main/org/jboss/portlet/forums/ui/view/ViewJumpbox.java
getWatchedTopics and getTopicWatches methods of src/main/org/jboss/portlet/forums/ui/view/ViewMyForumsAllSubscrived.java
getForumsLastPosts, execute and getWatchedForums methods of src/main/org/jboss/portlet/forums/ui/view/ViewMyForumsEditAllForums.java
getWatchedTopics, getForumsLastPosts and getWatchedForums methods of src/main/org/jboss/portlet/forums/ui/view/ViewMyForumsMain.java
loadDefaultTopics method of src/main/org/jboss/portlet/forums/ui/view/ViewSummary.java
3 - all methods use a FORUM_INSTANCE_ID constant declared into src/main/org/jboss/portlet/forums/ui/Constants.java to call foruminstanceid preferemce
--
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
17 years, 1 month
[JBoss JIRA] Updated: (JBAS-3258) JDBC artificats should throw SQLException when already closed
by Adrian Brock (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3258?page=all ]
Adrian Brock updated JBAS-3258:
-------------------------------
Comment: was deleted
> JDBC artificats should throw SQLException when already closed
> -------------------------------------------------------------
>
> Key: JBAS-3258
> URL: http://jira.jboss.com/jira/browse/JBAS-3258
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1
>
>
> In the change to fix JBAS-2741 I mistakenly made the JDBC wrappers throw an SQL
> exception if the artifact is already closed. They should just return with an exception.
> From the Javadoc:
> "Calling the method close on a Statement object that is already closed has no effect."
> e.g. In WrappedStatement
> public void close() throws SQLException
> {
> synchronized (lock)
> {
> if (closed)
> throw new SQLException("Already closed");
> closed = true;
> }
> lc.unregisterStatement(this);
> internalClose();
> }
> this should be:
> public void close() throws SQLException
> {
> synchronized (lock)
> {
> if (closed)
> return;
> closed = true;
> }
> lc.unregisterStatement(this);
> internalClose();
> }
--
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
17 years, 1 month
[JBoss JIRA] Commented: (JBAS-3258) JDBC artificats should throw SQLException when already closed
by Adrian Brock (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3258?page=comments#action_12389843 ]
Adrian Brock commented on JBAS-3258:
------------------------------------
Help requests go in the forums, not release notes.
> JDBC artificats should throw SQLException when already closed
> -------------------------------------------------------------
>
> Key: JBAS-3258
> URL: http://jira.jboss.com/jira/browse/JBAS-3258
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1
>
>
> In the change to fix JBAS-2741 I mistakenly made the JDBC wrappers throw an SQL
> exception if the artifact is already closed. They should just return with an exception.
> From the Javadoc:
> "Calling the method close on a Statement object that is already closed has no effect."
> e.g. In WrappedStatement
> public void close() throws SQLException
> {
> synchronized (lock)
> {
> if (closed)
> throw new SQLException("Already closed");
> closed = true;
> }
> lc.unregisterStatement(this);
> internalClose();
> }
> this should be:
> public void close() throws SQLException
> {
> synchronized (lock)
> {
> if (closed)
> return;
> closed = true;
> }
> lc.unregisterStatement(this);
> internalClose();
> }
--
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
17 years, 1 month
[JBoss JIRA] Updated: (JBAS-3258) JDBC artificats should throw SQLException when already closed
by Adrian Brock (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3258?page=all ]
Adrian Brock updated JBAS-3258:
-------------------------------
Comment: was deleted
> JDBC artificats should throw SQLException when already closed
> -------------------------------------------------------------
>
> Key: JBAS-3258
> URL: http://jira.jboss.com/jira/browse/JBAS-3258
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1
>
>
> In the change to fix JBAS-2741 I mistakenly made the JDBC wrappers throw an SQL
> exception if the artifact is already closed. They should just return with an exception.
> From the Javadoc:
> "Calling the method close on a Statement object that is already closed has no effect."
> e.g. In WrappedStatement
> public void close() throws SQLException
> {
> synchronized (lock)
> {
> if (closed)
> throw new SQLException("Already closed");
> closed = true;
> }
> lc.unregisterStatement(this);
> internalClose();
> }
> this should be:
> public void close() throws SQLException
> {
> synchronized (lock)
> {
> if (closed)
> return;
> closed = true;
> }
> lc.unregisterStatement(this);
> internalClose();
> }
--
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
17 years, 1 month
[JBoss JIRA] Commented: (JBAS-3258) JDBC artificats should throw SQLException when already closed
by Edoardo Causarano (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3258?page=comments#action_12389842 ]
Edoardo Causarano commented on JBAS-3258:
-----------------------------------------
Hi, we're having the same problem on our servers but I expected that the "jboss-4.0.4.GA-Patch1-installer.jar" contained the fix to this issue. Unfortunately the installer doesn't seem to contain said patch so we're a bit stuck; does it mean that we have to upgrade to 4.0.5?
> JDBC artificats should throw SQLException when already closed
> -------------------------------------------------------------
>
> Key: JBAS-3258
> URL: http://jira.jboss.com/jira/browse/JBAS-3258
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1
>
>
> In the change to fix JBAS-2741 I mistakenly made the JDBC wrappers throw an SQL
> exception if the artifact is already closed. They should just return with an exception.
> From the Javadoc:
> "Calling the method close on a Statement object that is already closed has no effect."
> e.g. In WrappedStatement
> public void close() throws SQLException
> {
> synchronized (lock)
> {
> if (closed)
> throw new SQLException("Already closed");
> closed = true;
> }
> lc.unregisterStatement(this);
> internalClose();
> }
> this should be:
> public void close() throws SQLException
> {
> synchronized (lock)
> {
> if (closed)
> return;
> closed = true;
> }
> lc.unregisterStatement(this);
> internalClose();
> }
--
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
17 years, 1 month
[JBoss JIRA] Created: (JBCACHE-1227) Data gravitation RspFilter makes cache misses very slow
by Brian Stansberry (JIRA)
Data gravitation RspFilter makes cache misses very slow
-------------------------------------------------------
Key: JBCACHE-1227
URL: http://jira.jboss.com/jira/browse/JBCACHE-1227
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.1.0.CR2
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Critical
Fix For: 2.1.0.GA
DataGravitatorInterceptor.ResponseValidityFilter will make all gravitation attempts take buddyCommunicationTimeout ms if the data is not available (i.e. if its a cluster-wide cache miss). Logging showing what happens with a 2 second buddyCommunicationTimeout :
2007-11-28 14:24:49,634 DEBUG [org.jboss.cache.interceptors.DataGravitatorInterceptor] cache=192.168.1.164:1621; requesting data gravitation for Fqn /JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-TomcatCache] callRemoteMethods(): valid members are [192.168.1.165:1674] methods: /JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher] dests=[192.168.1.165:1674], method_call=MethodName: gravitateData; MethodIdInteger: 35; Args: (/JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID, true), mode=1, timeout=2000
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 21
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.AbstractMarshaller] extract(): received MethodName: gravitateData; MethodIdInteger: 35; Args: (/JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID, true)extracted fqn: /JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call. Using region /JSESSION/localhost/http-field-pass
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object MethodName: gravitateData; MethodIdInteger: 35; Args: (/JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID, true)
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field-pass to stream
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher] real_dests=[192.168.1.165:1674]
2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Read version 21
2007-11-28 14:24:49,759 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Unmarshalled regionFqn /JSESSION/localhost/http-field-pass from stream
2007-11-28 14:24:49,759 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Unmarshalled object Result dataFound=false nodeData=null fqn=null
2007-11-28 14:24:51,759 DEBUG [org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher] responses: [sender=192.168.1.165:1674, retval=null, received=false, suspected=false]
The 2nd to last line shows the response being unmarshalled, yet 2 secs later the RpcDispatcher reports no response was received from the node that sent the response.
Cause is DataGravitatorInterceptor.ResponseValidityFilter.needMoreResponses() which will always return true until it gets a response where GravitateResult.isDataFound() is true. That response will never arrive if the data doesn't exist. So RpcDispatcher will keep waiting for more responses until it times out.
I think the solution is to pass the vector of members being called to ResponseValidityFilter, which keeps a copy. In isAcceptable, remove the member that sent the response. In needMoreResponses, return false if all members have sent responses.
I'll attach a patch implementing the above in a minute.
--
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
17 years, 1 month