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: <ju...@jb...> - 2005-08-04 21:56:28
|
today a page cannot exist without the portal being created first (that what not the case in 2.0 but that more flexible structure was not making the dynamicity easy to implement) I understand what you are meaning and why it is convenient, perhaps we'll find out a good solution to remedy to that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888524#3888524 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888524 |
From: jspaeth <nu...@jb...> - 2005-08-04 21:48:48
|
I agree that the lifecycles might be more closely related than they are now. However, the -pages.xml currently allows for the deployment of several related but separate .war files to compose a single portal as well as the ability to hot-deploy additional pages into the portlet in the future. I would suggest finding a way to keep this functionality if you choose to remove the -pages.xml functionality. Would probably require some type of dependency declarations between .war files? Just my two cents. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888523#3888523 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888523 |
From: dsouza42 <nu...@jb...> - 2005-08-04 21:45:13
|
Hi, I ran my test suite on EJB3 RC1 and it failed. I think it might be a bug. I have an entity bean with an ID declared as: | @Id(generate = GeneratorType.SEQUENCE, generator = "MySequence") | @SequenceGenerator(name = "MySequence", sequenceName = "MY_SEQ") | public Integer getId() { | ... | At some point I'm persisting the bean by calling the entity manager's persist() method. After that I need to delete the object from the database but I can't since getId() is now returning null even after the object is persisted. The sequence is working and the row is being inserted into the database without any problems. In previous versions, immediately after the call to persist(), I'd be able to call getId() on my entity bean and use it for any needed purpose. Is this behaviour correct? Is it a bug? I'm using EJB 3 RC1 on JBoss 4.0.3RC1 and Oracle 10g. Thanks, Denis Souza View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888521#3888521 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888521 |
From: <aco...@jb...> - 2005-08-04 21:04:54
|
ahh i get it now. checking out is slow for you? Do you use -z3 or better option? Its pretty speedy for me. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888515#3888515 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888515 |
From: mikezzz <nu...@jb...> - 2005-08-04 19:47:38
|
I was wanting to check out the build dist stuff. Plus I got bored of downloading after waiting for the wrong version of JBoss to be checked out. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888511#3888511 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888511 |
From: <sco...@jb...> - 2005-08-04 19:42:56
|
I have updated the generate-lib-file target in build-thirdparty.xml to run the ComponentRefGraphLicenseVisitor: | <target name="generate-lib-file" | description="generate libraries.ent and thirdparty license info" | depends="synchronize"> | <gen-lib-file filename="${generatedLibrariesFiles}" /> | <visit-componentref-graph | componentVisitor="org.jboss.ant.util.graph.ComponentRefGraphLicenseVisitor" /> | </target> | | This pulls down the license files for all active license types to thirdparty/licenses and builds a thirdparty/licenses/thirdparty-licenses.xml xref that is similar to what we had before. Additional xrefs that would be useful are: - artifact-users.xml : for every single artificat in thirdparty, list the components that reference it. - component-artifacts.xml : for every component, provide a complete list of its artifacts including imported artifacts. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888509#3888509 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888509 |
From: <sco...@jb...> - 2005-08-04 19:09:30
|
Changes: - A ComponentRef has a SortedSet that are the set of compatible elements in an import statement: when this set is populated, the version is set to the last Compatible.version. This means that the comparision/sorting of Compatibles has to make sense in terms of the dot decimal tupple a version represents. I doubt this is currently correct as its simply using the String.compareTo. Unfortunately the java.lang.Package class has not public constructor so that we could use this. We'll just need a proper Version class. - An Import has a reference to the Component it belongs to. We should be able to use this to provide better feedback on where version conflicts occur. This is also passed to the ComponentRef created from the Import. - The SynchronizeComponentsTask version check validates that ComponentRef.compatibles set against the component version being imported now rather than just doing a version to version comparison. We need the new Version class in order for this to be robust. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888503#3888503 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888503 |
From: <aco...@jb...> - 2005-08-04 18:54:58
|
anonymous wrote : | I had a quick go with the new installer. Looks good I think it is definitely the way forward. I didn't get a running version as I had some problems checking out 4.0.3 rc3 (cvs co jboss-4.0 gives you 5.0.0) and tried to make it work on 4.0.2, which doesn't seem to like exploded har files. Will get 4.0.3 this weekend and get it working. | Oh mike, how come you didn't try letting the installer create your jboss? It has a copy in it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888500#3888500 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888500 |
From: <sco...@jb...> - 2005-08-04 17:12:14
|
In testing the thirdparty/licenses creation I saw that some component references in the 4.0 build-thirdparty.xml were using the wrong version. The primary example being the reference to the apache-logging version 1.0.3 which should be the 1.0.4jboss version. Changing this and rerunning the build produced: C:\cvs\JBoss4.0\jboss-4.0\build\build-thirdparty.xml:185: A versioning problem exists: Component: apache-logging is already defined as using version 1.0.4jboss but it is also required to be at version 1.0.3 I created a bug report for this with some additional details: http://jira.jboss.com/jira/browse/JBBUILD-126 Here we need to determine how we are going to deal with versioning. The immeadiate 2 problems are that the resolution process is not keeping track of what are the components involved at the point of the version conflict. It is not the apache-logging component that is referring to two versions. It is that some component has an import of apache-logging version 1.0.3 while the existing apache-logging component says its version 1.0.4jboss. The second problem is that the Import.CompatibleVersions is not being used correctly. This was a vector of Compatible objects and only the first value was being used as the ComponentRef version. The Import.CompatibleVersions needs to be a sorted set with the entire set used to determine if the current project Component has a version that is compatible with the ComponentRef compatibles version set. I'm working on getting this to a working state for the current 4.0 build so I can finish the installer for the 4.0.3RC2 release. This is something we have to get correct and working before the thirdparty mechanism can really be used. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888487#3888487 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888487 |
From: <bil...@jb...> - 2005-08-04 16:53:13
|
JBoss EJB 3.0 RC1 - JBoss AS integration We are getting closer to offering a professionally supportable release of EJB 3.0 with JBoss EJB 3.0 RC1. There are a lot of bugs fixed and and a lot of the features that are in the EJB 3.0 Public Draft have been implemented. We have also done even tighter integration with Hibernate 3.1. You can now inject a Hibernate Session or SessionFactory using the @PersistenceContext annotation. Hibernate Sessions will be managed and behave exactly like injected EntityManagers. You can view the release notes and download from here: http://www.jboss.com/products/list/downloads#ejb3 Use full EJB 3.0 out of the application server! JBoss EJB 3.0 supports an embeddable version that can be run outside of the application server in standalone applications, junit tests, Tomcat, or even other non-jboss application servers. This is an alpha release as there are a few issues we haven't fully worked out yet as you will see below. You can find out more information about it here: http://docs.jboss.org/ejb3/embedded/embedded.html[/url] and can download it here: [url]http://www.jboss.com/products/list/downloads#ejb3 Supported Features: * Local JNDI * Transaction Manager * JMS * Local TX datasource/connection pool * Stateful, Stateless, Service, Consumer, Producer, and MDBs * EJB 3 Persistence * Hibernate integration Limitations: * We have only sparsely tested the embedded stack. Consider it an alpha release * The Embedded stack is based off of CVS HEAD, not JBoss 4.0.x. Future versions will be based off of 4.0.x code. * We have done no pruning of jar files so the distribution disc size is a little large. * Documentation is sparse. Hopefully the tutorial examples are enough to get started. * We have not tested yet in other application servers, only within standalone Tomcat. No reason why it shouldn't work though * We cannot yet take advantage of services like JNDI, TM, JMS, etc... when running in other app servers * When embedding into Tomcat, you still require a JBoss specific JNDI implementation. Tomcat's JNDI is read-only. * EJB/JBoss Security is not available yet. * XA Connection pool is not available yet. * EJB Timer service not supported * Distributed remote communication is not supported yet. ** Even though @Remote interfaces are supported, you can only communicate through local colocated connections. ** You cannot access JMS remotely. Only locally. Thus, you have to lookup the "java:/ConnectionFactory". ** JNDI is not available remotely View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888484#3888484 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888484 |
From: <ad...@jb...> - 2005-08-04 15:53:14
|
"aco...@jb..." wrote : | cvs co -r Branch_4_0 jboss-4.0 | cvs co -r Branch_4_0 jboss-4.0.x View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888471#3888471 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888471 |
From: <ad...@jb...> - 2005-08-04 15:48:25
|
No that is not a valid change. isReadOnlyTxLock is redundant. If the lock really is "read only" there will be no transaction synchronization. If there is a transaction synchronization, it will be because it has been upgraded to a write lock and the synchronization will release the lock at the end of the transaction. See EntitySynchronizationInterceptor$InstanceSynchronization::afterCompletion View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888469#3888469 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888469 |
From: <ani...@jb...> - 2005-08-04 15:47:42
|
I agree on the XSModel to be included inside the RW based JBossXSModel. I created a top priority JIRA issue for this: http://jira.jboss.com/jira/browse/JBWS-348 It was only by trial and error that I learnt that the Xerces implementation of XSModel is read only and they do not recommend using their api/model for writing purposes. This was the reason I had to create a seperate JBossXSModel. Another factor that affected tools was the migration of the wsdl metadata into the server module and now its back in the webservices module. The reappearance of the wsdl metadata into webservices module is good because it will simplify tools code. Now regarding the JavaToXSD api, I have to disagree a bit. My original intent was to have JavaToXSD to just generate a XSTypeDefinition given a Java class. The introspection of the class for methods and properties, was a concern of the JavaToWSDL layer. But now I see your feedback and on second thought, I think what you are asking is achievable and will be suitable. The concern of dealing with the class internals can be either with the JavaToWSDL layer or with the JavaToXSD subsystem. I prefer the former and you wish to have the latter. So will get that to you. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888468#3888468 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888468 |
From: <aco...@jb...> - 2005-08-04 14:40:51
|
modules limit directories, you still need the tag cvs co -r Branch_4_0 jboss-4.0 anonymous wrote : | Choosing between a new or existing jboss install is a little clumsy. On the Installation location page it would nice to have 3 radio button options: | | - New install, with text field and browse button. | - Existing install, with text field, browse button and select box indicating with server configuration to use (we could produce a list once the directory is selected). We could also default the jboss installation from the JBOSS_HOME environment variable if it exists. | - Create deployable EAR. Useful for deploying to headless servers/clusters. | I think you're on to something, but we'll have to defer that to a later milestone because it involves changes to izPack and probably coordination with the overall JBoss Build project. I'm sure scott/clan would be ameniable to this (since it has larger uses), but it involves too many touch points to get out for M3. (The installation panel is more or less a fixed panel) anonymous wrote : | In the longer term it would be nice to support more advanced configurations and be able to set all of the options on all of the MBeans. E.g. being able to set options for performance tuning would be nice. Perhaps an "Advanded" button on some of the pages which shows more detailed options. | Yes. I vacillate on this. We're going to need an admin tool so should the installer let you do that or require you to do that in the admin tool? My present thinking is that it should once automated install works properly so that you can install consistantly accross an organization. Though I have more sinsiter plans for MBeans and all. anonymous wrote : | I also noticed that if you reinstall it over an existing install it fails. Something to do with keystore generation. | I'll probably cover this in the readme. I don't want to mindlessly clobber an ssh key. It should work if you don't generate a new key. ======= That stuff aside, are you cool with the dev and dev-deploy targets? I wanted to find a way to keep the install working consistantly. This will probably mean everyone has to grok just a little bit about izPack. I don't think groking the velocity templates is that hard (if one understands if statements and ant basically ;-) ). There are minor gotchas but one figures them out quickly (no ${foo.bar} type variable names mostly because it thinks the dot means class member) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888454#3888454 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888454 |
From: <tom...@jb...> - 2005-08-04 14:26:23
|
ok thanks. regards, tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888451#3888451 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888451 |
From: <ale...@jb...> - 2005-08-04 14:26:03
|
AFAICS in our testsuite, when I see a type in an XSD defined following this 'array' template, it's not necessarily bound to an array in Java. For example. testsuite/src/resources/webservice/marshalltest-doclit/META-INF/wsdl/MarshallDocLitService.wsdl | <complexType name="LongArr"> | <sequence> | <element name="longArr" type="long" minOccurs="0" maxOccurs="unbounded"/> | </sequence> | </complexType> | Isn't this TYPE bound to a class that wrapps the array? | package org.jboss.test.webservice.marshalltest.types; | | public class LongArr | { | private long[] longArr; | | public LongArr() | { | } | | public LongArr(long[] longArr) | { | this.longArr = longArr; | } | ... | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888450#3888450 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888450 |
From: arvinder <nu...@jb...> - 2005-08-04 14:23:29
|
Hi In terms of the message channels/bus within the integration environment, for a given bus you could specify the way a message is handled, say through meta information contained in the request to specifiy invocation type, e.g request-response or request only aka fire and forget. This is similar to what the spec has defined interms of the normalized message exchange. So within the integation environment, you have several service engines/binding components that could listen in on a specific channel, say a control channel, that is used to send control based messages to these components. At this point you also make the service/engine and binding components use an event channel to send ... events to interested parties etc. This is what i was referring to about different channels etc. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888449#3888449 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888449 |
From: <tom...@jb...> - 2005-08-04 14:15:53
|
could you elaborate ? i don't your point yet. regards, tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888447#3888447 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888447 |
From: arvinder <nu...@jb...> - 2005-08-04 14:13:11
|
You would need multiple bus abstractions, think multiple channels, some for control, some for event, some domain specific etc. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888446#3888446 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888446 |
From: <dim...@jb...> - 2005-08-04 12:46:03
|
webservices-wise, is there any particular reason for including xalan.jar in ./lib/endorsed? It's certainly not used for bootstraping jboss. I'm trying to find out what is the correct location, 3.2.7 has it in server/{default|all}/lib, but the 4.x branch in ./lib/endorsed. There is a jira case about it: http://jira.jboss.com/jira/browse/JBAS-2073 Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888427#3888427 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888427 |
From: ryoung2504 <nu...@jb...> - 2005-08-04 10:08:09
|
Thanks, but its not an entity manager that I'm trying to inject so @PersistenceContext doesn't work either. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888393#3888393 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888393 |
From: megid <nu...@jb...> - 2005-08-04 09:55:30
|
Hello, See: http://wiki.jboss.org/wiki/Wiki.jsp?page=MigrationFromPreview5ToEJB3.0Beta @Inject is now @PersistenceContext. Kind regards. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888389#3888389 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888389 |
From: mjtodd <nu...@jb...> - 2005-08-04 08:50:20
|
I have been experiencing problems where the deadlock detector was detecting deadlock after a series of calls on read-only methods. It is my understanding that when calling a sequence of entirely read-only methods that deadlock should not occur. I have looked at the code for QueuedPessimisticEJBLock and the comment at the top indiciates that for read-only method the lock is released at the end of the invocation. This does not seem to be the case. I have made the following modification to the code of endInvocation: if (ctx == null || ctx.hasTxSynchronization() == false) | endTransaction(tx); I changed to if (ctx == null || ctx.hasTxSynchronization() == false || isReadOnlyTxLock) | endTransaction(tx); Is this a valid code change to fix the issue, or have I not fully understood the code? Without my change then isReadOnlyTxLock is never used. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888379#3888379 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888379 |
From: ptournet <nu...@jb...> - 2005-08-04 08:42:42
|
I don't mind at all Roy, it was intended to be used... But I rather post here to get more feedback... I'm still trying to configure Eclipse, so the project can be automatically build from within. If I run the build/build.xml file as an Ant Build, I get the following error : BUILD FAILED D:\Eclipse\JBoss-Portal-and-samples\jboss-portal-2.0\tools\etc\buildfragments\tools.ent:153: taskdef A class needed by class org.apache.cactus.integration.ant.CactusTask cannot be found: junit/framework/Test So if anyone has an idea of what happens and how to overcome it, I would be gratefull... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888378#3888378 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888378 |
From: mikezzz <nu...@jb...> - 2005-08-04 07:48:35
|
Hi Andy, I had a quick go with the new installer. Looks good I think it is definitely the way forward. I didn't get a running version as I had some problems checking out 4.0.3 rc3 (cvs co jboss-4.0 gives you 5.0.0) and tried to make it work on 4.0.2, which doesn't seem to like exploded har files. Will get 4.0.3 this weekend and get it working. A couple of comments, these are mostly cosmetic and pie in the sky stuff. Choosing between a new or existing jboss install is a little clumsy. On the Installation location page it would nice to have 3 radio button options: - New install, with text field and browse button. - Existing install, with text field, browse button and select box indicating with server configuration to use (we could produce a list once the directory is selected). We could also default the jboss installation from the JBOSS_HOME environment variable if it exists. - Create deployable EAR. Useful for deploying to headless servers/clusters. The packages screen would be read-only as the above selection will dictate what pacages to use. In the longer term it would be nice to support more advanced configurations and be able to set all of the options on all of the MBeans. E.g. being able to set options for performance tuning would be nice. Perhaps an "Advanded" button on some of the pages which shows more detailed options. I also noticed that if you reinstall it over an existing install it fails. Something to do with keystore generation. Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888370#3888370 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888370 |