Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: dajevtic <nu...@jb...> - 2005-05-16 12:38:51
|
Of course. Here is a small code snippet of how it can be used:
Portlet with form:
public void processAction(ActionRequest request, ActionResponse response) {
PortletFormManager.getInstance().setFormData(request);
}
places all request parameter names and parameter values into the PortletFormManager.
Portlet displaying the values:
Hashtable requestParameters = PortletFormManager.getInstance().getObject(request.getPortletSession().getId());
if (requestParameters != null) {
Iterator parameterValues = requestParameters.values().iterator();
while (parameterValues.hasNext()) {
System.out.println((String)parameterValues.next());
}
}
This is the easiest way. The PortletFormManager also has methods for retrieving the form data as a Map, Collection or Enumeration.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877822#3877822
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877822
|
|
From: <ju...@jb...> - 2005-05-16 11:38:16
|
could you give example for instance of how it can be used ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877821#3877821 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877821 |
|
From: dajevtic <nu...@jb...> - 2005-05-16 11:36:24
|
I have developed a PortletForm class, which is similar to the above example. It can be configure to accept any form data posts from a user for a specific portlet and make the form data available to another registered portlet (for the same user). This may be a nice solution for Jboss Portal to handle forms inside portlets and communicate them to other portlets. What do you think? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877820#3877820 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877820 |
|
From: dajevtic <nu...@jb...> - 2005-05-16 11:30:09
|
Ok, solved the problem myself. Using <%@ taglib uri="http://jakarta.apache.org/taglibs/core" prefix="c" %> instead of <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %> fixed it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877819#3877819 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877819 |
|
From: dajevtic <nu...@jb...> - 2005-05-16 10:02:12
|
Certainly, I would be glad to contribute any helpful tools required for interportlet communication. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877811#3877811 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877811 |
|
From: <ju...@jb...> - 2005-05-16 09:55:03
|
would you work on implementing in JBoss Portal under a "tools" module that would contain various tools for inter portlet communication ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877810#3877810 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877810 |
|
From: dajevtic <nu...@jb...> - 2005-05-16 09:35:09
|
Hello everyone. Even though this problem is not fatal, I would still like to know if anyone has experienced (and solved) the following:
Some JSTL tags are not behaving correctly.
The following sample code does not produce the desired output:
<c:forEach items="blab,blob,blub" var="yo">
<input type="text" value="<c:out value="${yo}"/>"/>
</c:forEach>
Even though 3 textfields are produced (which means c:forEach is working fine), all textfields have a value of ${yo} instead of blab, blob and blub. Further tests, trying to print out other things with c:out produce the same unsatisfactory results.
Any idea, if this is a problem within the portal, because using this code on a JSP outide a portal works just perfectly.
Thanks in advance.
Regards, dj
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877808#3877808
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877808
|
|
From: dajevtic <nu...@jb...> - 2005-05-16 09:22:04
|
A good idea would be to use the session Id of the user as the key. That way, another portlet could retrieve the object by just passing the session id to the Manager class and retrieve the contents. We mainly use this to store request parameters which are posted from one portlet and being retrieved by another one. This can be implemented as a stack as well, pushing parameters from one portlet and popping the parameters from another portlet. I'll be glad to help if anyone has problems/questions regarding this matter. Regards! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877806#3877806 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877806 |
|
From: <max...@jb...> - 2005-05-16 08:35:14
|
...and they have a site.xml for nightly/integration build and site-release.xml for actual releases it seems (thus providing two different update sites at the same location) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877805#3877805 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877805 |
|
From: <max...@jb...> - 2005-05-16 08:32:43
|
went to the EMF site and found the following docs at http://download.eclipse.org/tools/emf/scripts/docs.php?doc=docs/UsingUpdateManager/UsingUpdateManager.html "If you're installing from the Eclipse.org update site, you will not see the 4th part of the version, that is, you will see 2.0.0 instead of 2.0.0.R200406280827. Note also that due to the way that Eclipse handles plugin versioning, to update from 2.0.0.I to 2.0.0, or 2.0.1.M to 2.0.1 is not possible. You cannot update from a 4-part version to its equivalent 3-part version, since Update Manager considers that 2.0.0 < 2.0.0.R. You can, however, upgrade from 2.0.0.R to 2.0.1. So, to move from an I or M build to its Release, you must either uninstall/disable that version and install fresh, or update from 2.0.1.M to 2.0.1.R (not 2.0.1), keeping that 4th version part intact." so they have the exact same problem. they solve it in to ways... #1: tell users to disable the installed feature and then let the user select the proper version #2: add an .R to the end to make it "higher" then any nightly/integration build /max View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877804#3877804 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877804 |
|
From: icecrash <nu...@jb...> - 2005-05-16 07:37:16
|
why if i make a root class pool and a child classpool ,when i reference a ctclass from child class pool , i do not see all method from that?
i make a root class pool:
| ClassPool RootClassPool;
| RootClassPool = new ClassPool();
| RootClassPool.getDefault();
|
i make a child classpool:
| ClassPool CP;
| CtClass CTCLASSE;
| .
| .
| .
| CP = new ClassPool(RootClassPool);
| try {
| CTCLASSE = CP.get("className");
| }
| catch(Exception e){System.err.println(e);}
| .
| .
| .
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877800#3877800
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877800
|
|
From: <ju...@jb...> - 2005-05-16 01:17:09
|
I want to make an RC2 next week after the changes made to the codebase in order to have it running on 4.0.2. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877794#3877794 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877794 |
|
From: <ju...@jb...> - 2005-05-16 01:08:59
|
Thanks for sharing the idea. It is part of the thing we would like to add in future release. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877793#3877793 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877793 |
|
From: <ju...@jb...> - 2005-05-16 01:08:20
|
I have updated the codebase in order that JBoss Portal 2.0 executes only on JBoss AS 4.0.2 which is the target platform for the release. Everything seems to work which includes : - new classloader model for web app - hibernate 3 is used The bonus is that now jboss-portal.sar is independant of the target database. So please use JBoss 4.0.2 with CVS head. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877792#3877792 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877792 |
|
From: bryan_castillo <nu...@jb...> - 2005-05-15 22:20:27
|
Call pointcuts are supported with loadtime AOP. I just had my bootclasspath setup wrong. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877789#3877789 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877789 |
|
From: timfox <nu...@jb...> - 2005-05-15 20:08:05
|
I've submitted a patch attached to JIRA JBMESSAGING-38. It contains the initial implementation for the JMS Queue Browsing functionality. It also contains several changes, mainly to messaging core classes to be able to discriminate between asynch and no asynch acknowledgements. Asynch. acks are now supported for Queues. I haven't implemented them for durable subsribers yet though. The patch is fairly large, mainly because the Receiver.handle() signature has changed, touching a lot of files. Most of the changes to these files are trivial though. All tests now pass. -Tim View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877788#3877788 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877788 |
|
From: <roy...@jb...> - 2005-05-15 17:31:13
|
You can find the chapter here: http://docs.jboss.org/jbportal/v2.0RC/reference-guide/en/html/themeandlayouts.html You can find the sample war here: http://download.jboss.com/jbossportal/themes/myLayout.war.zip View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877784#3877784 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877784 |
|
From: bryan_castillo <nu...@jb...> - 2005-05-15 14:36:35
|
Does JBoss AOP support pointcuts on calls (instead of execution) using loadtime AOP (the generated class loader)? The example for call pointcuts uses the precompiler. I tried to do it anyway and it doesn't seem to be working. I don't know if its not supported or if I'm doing it wrong though. Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877778#3877778 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877778 |
|
From: dajevtic <nu...@jb...> - 2005-05-15 10:32:29
|
Sorry, forgot to mention that portlets accessing this Manager must run in the same JVM (on the same server) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877776#3877776 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877776 |
|
From: dajevtic <nu...@jb...> - 2005-05-15 10:26:13
|
Hi. There may be no standard, but this code works just fine for us. Define a class to which all portlets have access and change it according to your needs:
import java.util.Hashtable;
public class InterPortletCommManager {
private static InterPortletCommManager thisMgr = null;
private Hashtable something;
private InterPortletCommManager() {
try {
something = new Hashtable();
// do any initialization of local variables here
}
catch (Exception ex) {
}
}
public static InterPortletCommManager getInstance() {
if (thisMgr == null) {
thisMgr = new InterPortletCommManager();
}
return thisMgr;
}
public Object getObject(String portletId) {
// retrieve an Object by using a portlet ID
return something.get(portletId);
}
public void setObject(String portletId, Object someObject) {
// use the ID of a portlet as a key for the object to be stored
something.put(portletId, someObject);
}
}
with InterPortletCommManager.getInstance() all portlets have access to the Vector "something". Of course you can create other methods and other objects to use amongst all portlets.
Hope it helps. Regards, dj
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877775#3877775
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877775
|
|
From: <sco...@jb...> - 2005-05-14 17:43:39
|
I'm still struggling with how best to resolve dependency import notion in this issue: http://jira.jboss.com/jira/browse/JBBUILD-72. The problem I'm seeing is that there already is a notion of dependency, but it does not seem to be at the correct level. Its showing up in the main component build rather than the component-info.xml. Take for example, the jboss-head/naming/component-info.xml: | <project name="naming-component-info"> | | <component id="naming" | module="jboss-naming" | version="5.0-SNAPSHOT" | > | <artifact id="jnpserver.jar"/> | <artifact id="jnp-client.jar"/> | <artifact id="jnp-tests.jar"/> | <export> | <include input="jnpserver.jar"/> | </export> | </component> | | | </project> | and the jboss-head/naming/jbossbuild.xml: | <?xml version="1.0"?> | | <project name="project" | default="build" | basedir="." | > | <import file="../tools/etc/jbossbuild/tasks.xml"/> | <import file="component-info.xml"/> | | <componentdef component="naming" description="JBoss Naming"> | | <source id="main" | rmic="**/NamingServer.class" | > | <include component="common"/> | <include component="apache-log4j"/> | <include component="junit-junit"/> | </source> | | <artifactdef artifact="jnpserver.jar"> | <include input="main"> | <!-- include server classes & interfaces --> | <include pattern="org/jnp/server/**"/> | <include pattern="org/jnp/interfaces/**"/> | </include> | </artifactdef> | | <artifactdef artifact="jnp-client.jar"> | <include input="main"> | <!-- include client classes & server stubs --> | <include pattern="org/jnp/interfaces/**"/> | <include pattern="org/jnp/server/*Stub.class"/> | </include> | </artifactdef> | | <artifactdef artifact="jnp-tests.jar"> | <include input="main"> | <!-- only include test classes --> | <include pattern="org/jnp/client/**"/> | <include pattern="org/jnp/test/**"/> | </include> | </artifactdef> | </componentdef> | | <!-- Generate the targets --> | <generate generate="naming"/> | | </project> | | So there is an expression of the thirdparty dependencies in the source id="main" element via the include component=common, apache-log4j, and junit-junit. This should be coming from the imported component-info.xml so that when the jnpserver.jar is promoted to the repository, consumers of the jnpserver.jar have the same thirdparty dependencies defined. In this case, only the common and apache-log4j should be in expressed as dependencies in the component-info.xml as the junit-junit is local to the naming module unit testing. So something like the following component-info.xml: | <project name="naming-component-info"> | <component id="naming" | module="jboss-naming" | version="5.0-SNAPSHOT" | > | <includes id="thirdparty"> | <include component="common"/> | <include component="apache-log4j"/> | </includes> | <artifact id="jnpserver.jar"/> | <artifact id="jnp-client.jar"/> | <artifact id="jnp-tests.jar"/> | <export> | <include input="jnpserver.jar"/> | </export> | </component> | </project> | and componentdef/source is how this should be tying together: | <componentdef component="naming" description="JBoss Naming"> | <source id="main" | rmic="**/NamingServer.class" | > | <include includesref="thirdparty"/> | <include component="junit-junit"/> | </source> | right? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877763#3877763 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877763 |
|
From: <sn...@sh...> - 2005-05-14 13:28:50
|
P.S. anonymous wrote : | What sort of tests would be appropriate? | If you get a false positive, or a spam get's through the best way to identify why is to test that single email (if you can) against the ScanFile test tool provided with jASEN. This will scan the message and display the results of each plugin in the engine (to standard out). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877753#3877753 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877753 |
|
From: <sn...@sh...> - 2005-05-14 13:13:33
|
anonymous wrote : | I would like to see this implemented, such that it can be loaded from an RDBMS (hibernate is your friend). | Agreed. I have used Hibernate in a previous project and have found it to be better than a cold beer on a hot day (not withstanding the time I was banned from the Hibernate forum for being a rude pr@#k) The only reason this is not the default implementation is so the engine can be immediately tested and usable. The objective is that jASEN provides a framework first and foremost, and a default (reference) implementation as a secondary consideration. Having said that, the default implementation is currently being used in a commercial production system... The implementation of a JasenMapStore class is a very simple task (it literally consists of two methods.. load and save). The creation of a compatible db schema is a separate issue but is still pretty simple (really just a list of words and associated probabilities obtained during training). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877751#3877751 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877751 |
|
From: mhaerdi <nu...@jb...> - 2005-05-14 10:04:29
|
still the same error... in the tcp/udp traffic on the client side i found at least one udp addressed to the server's internal address (192.168.x.x) according to http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_Transports_Configuration, I changed the file jboss-service.xml in \jboss-4.0.2\server\all\deploy\ejb3.deployer\META-INF to: <?xml version="1.0" encoding="UTF-8"?> | <server> | <mbean code="org.jboss.ejb3.EJB3Deployer" name="jboss.ejb3:service=EJB3Deployer"> | <depends>jboss.aop:service=AspectDeployer</depends> | </mbean> | <mbean code="org.jboss.remoting.transport.Connector" | xmbean-dd="org/jboss/remoting/transport/Connector.xml" | name="jboss.remoting:type=Connector,transport=socket3873,handler=ejb3"> | <depends>jboss.aop:service=AspectDeployer</depends> | <!--attribute name="InvokerLocator">socket://192.168.123.1:3873</attribute> | <attribute name="Configuration"> | <handlers> | <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler> | </handlers> | </attribute--> | <attribute name="Configuration"> | <config> | <invoker transport="socket"> | <attribute name="numAcceptThreads">1</attribute> | <attribute name="maxPoolSize">303</attribute> | <attribute name="clientMaxPoolSize">304</attribute> | <attribute name="socketTimeout">10000</attribute> | <attribute name="serverBindAddress">192.168.123.1</attribute> | <attribute name="serverBindPort">3873</attribute> | <attribute name="clientConnectAddress">212.254.183.234</attribute> | <attribute name="clientConnectPort">3873</attribute> | <attribute name="enableTcpNoDelay" isParam="true">false</attribute> | <attribute name="backlog">200</attribute> | </invoker> | <handlers> | <!--handler subsystem="mock">org.jboss.remoting.transport.mock.MockServerInvocationHandler</handler--> | <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler> | </handlers> | </config> | </attribute> | </mbean> | </server> 192.168.123.1 is the internal address of the server in the lan 212.254.183.234 is the external address of the server (firewall wan-ip) i still start jboss with run.bat -c all -Djava.rmi.server.hostname=212.254.183.234 -Djava.rmi.server.useLocalHostname=false The client connects with java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces java.naming.provider.url=jnp://212.254.183.234:1099 what is wrong/missing? "tom...@jb..." wrote : Since the ip is 0.0.0.0, the server will just bind to its local host and use that ip as the address it tells clients to connect to. This is probably something like 192.168.1.1. The client, which is outside the firewall, probably does not access the server machine via the previous ip, but via some external ip (i.e. 56.23.35.2). Since the server does not know explicitly what this ip is, it can not tell the client to use this ip. You can change the address that the client tried to connect to the server on by changing the configuration (see http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_Transports_Configuration). | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877744#3877744 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877744 |
|
From: mikezzz <nu...@jb...> - 2005-05-14 07:04:08
|
anonymous wrote : 2. Implement your own JasenMapStore class. This is the actual "database" of heuristics. The default implementation loads the DB info memory by you can implement it however you like. I would like to see this implemented, such that it can be loaded from an RDBMS (hibernate is your friend). anonymous wrote : What sort of tests would be appropriate? Mostly check that when a message is submitted to the engine, that a X-SpamScore is applied. Don't go overboard unit testing how appropriate the score is as we don't really need unit test jASEN. Perhaps one spam and one non-spam to test both cases. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877736#3877736 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877736 |
1965 messages has been excluded from this view by a project administrator.
