RE: [JBoss-dev] Release 2.4.5 ??
by the way, could someone integrate my patch https://sourceforge.net/tracker/index.php?func=detailaid=512854group_id=22 866atid=376687 It seems to work well (the main problem is explaing what/how you can do with it), but despite the fact I'm allowed to write, I cannot use CVS because of our firewall... moreover I've tested all with jboss2.4.4 (+tomcat 4.0.1 .2 .3 ) but not in jboss3.x -Message d'origine- De: Thieme, Winfried [mailto:[EMAIL PROTECTED]] Date: lundi 25 mars 2002 16:39 À: '[EMAIL PROTECTED]' Objet: [JBoss-dev] Release 2.4.5 ?? Hello! Can anyone tell me when JBoss 2.4.5 will be released? Days, weeks, months ?? I'm waiting for a bug fix of bug #504895 ... Thanx Winfried ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Question for win32 batch file gurus
-Message d'origine-
De: Jason Dillon [mailto:[EMAIL PROTECTED]]
Date: samedi 16 février 2002 02:30
À: Jboss-Development@Lists. Sourceforge. Net
Objet: [JBoss-dev] Question for win32 batch file gurus
Is there any way to detect the directory in which a .bat file
lives when
it is running?
%~dp0 or equivalent %~d0%~p0
(translation in human: disk and path of the 0 variable ... you can get also
the name and option)
look in for/? for detail (why in for/?, because microsoft)
look in set/? call/? for some more...
not that it works only with CMD.EXE NT shell with extension activated (tha
default)..
probably also on 2000, BUT not on 95/98...
this is why it is often not used for most OpenSource project scripts...
for XP ? dunno
classic starting for a runserver.bat :
@echo off
setlocal
set cmd_dir=%~dp0
for /f tokens=* %%i in ('cd') do set current_dir=%%i
title foo bar server
...
goto end
:error
echo problem with
pause
:end
echo Bye...
endlocal
Like in sh, I can `dirname $0` to find out where the script lives.
Is this possible? If so can some one show me the syntax?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] catalina Connector customizing... bug/patch/ideas (was: org/jboss/web/catalina ajp13connector support)
-Message d'origine- De: Luke Taylor [mailto:[EMAIL PROTECTED]] Coetmeur, Alain wrote: by the way your ideas seems good, and moreover to help people whou want to explicitly configure each of their catalina connector (like the people tryin to have both http and https), the type none could be added with the only changes at if( type.equals(http) == false type.equals(warp) == false type.equals(ajp)==false type.equals(none) ) what about just using if(type.equals(none)) :) #8)) right, in fact I have done it yesterday, and this works... I have experimented few changes: 1- the none kind of connector it differs from my proposition here in the fact that I create the catalina engine even for the none (same code as HTTP connector but without the connector) 2- allowing Engine, Service Host Server elements in Config attribute I've found no code in the confighandle to support Engine elements in the Config attribute. We always need an Engine, but it may be cool to allow the user to configure it more precisely. but if the user is allowed to configure the engine, the none kind of connector have not to create one. maybe will I try that soon. Host elements, may also be interesting to support. SERVER and SERVICE parameters may too... 3- added MBEan parameters for HTTO-HTTPS redirectPort and for reverse Proxy I've also patched the catalina MBean so that it now support redirectPort, proxyName and proxyServer parameters but in fact with the None connector type, and the Config attribute these change are not needed... all one have to do is to configure all the connectors he wants in the Config attribute. by the way I've found 2 problems, solved one, and turned around the second 4- DOM to SAX conversion (catalina Mbean dependent on crimson implementation) the Config Handler class used by catalina MBean have to convert the XML Element from DOM to Sax, and do that through the toString() method of DOM Elements that, in crimson parser, serialize the Element as XML text. then the config handler parse it with Sax. however with xerces this does not work (toString is not in the standard, and I need xerces for cocoon) my solution have been to implement a DOM to SAX conversion function that just navigate in the tree and call the SAX handler methods as needed... this works well... 5- Multiple XML Top Elements in MBean XML Attribute are not supported and the problem is not signaled the second problem is that only ONE DOM Element is read by the Attribute in the MBean property is a DOM Element... moreover this is not checked and thus the following siblings are silently ignored by example you can try to configure 2 Connector elements with catalina MBean, but only the first will be read !!! the turnaround is just to create a SERVICE element that embeds many connectors... In fact I did it myself adding the SERVER and SERVICE (which are BTW needed for the SERVER/SERVICE/Connector/Listener element) eg this config seems to work, and could serve a a model (be carefull, I've not tested all, especially the http-https redirectPort and the proxy) : note that the redirectport attribute work only with my own version of the catalina Mbean (I'll send it here soon as a proposed patch) !-- Embedded Tomcat 4.x - JBossSX SecurityDomain (JaasSecurityDomain) -- mbean code=org.jboss.security.plugins.JaasSecurityDomain name=Security:name=JaasSecurityDomain,domain=tomcat constructor arg type=java.lang.String value=tomcat / /constructor attribute name=KeyStoreURL../conf/tomcat.jks/attribute attribute name=KeyStorePasschangeit/attribute /mbean mbean code=org.jboss.web.catalina.EmbeddedCatalinaServiceSX name=DefaultDomain:service=EmbeddedTomcat attribute name=Port80/attribute attribute name=ConnectorTypehttp/attribute attribute name=RedirectPort443/attribute attribute name=Config Server Service Connector className=org.apache.catalina.connector.http.HttpConnector port=8080 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=6/ Connector className=org.apache.catalina.connector.http.HttpConnector port=8443 minProcessors=5 maxProcessor=75 acceptCount=10 enableLookups=true scheme=https secure=true Factory className=org.jboss.web.catalina.security.SSLServerSocketFactory securityDomainName=java:/jaas/tomcat clientAuth=false protocol=TLS / /Connector Connector className=org.apache.catalina.connector.http.HttpConnector port=443 minProcessors=5 maxProcessor=75 acceptCount=10 enableLookups=true scheme=https secure=true Factory className=org.jboss.web.catalina.security.SSLServerSocketFactory securityDomainName=java:/jaas/tomcat clientAuth=false protocol=TLS / /Connector
RE: [JBoss-dev] org/jboss/web/catalina ajp13connector support
-Message d'origine- I was wondering if there were a particular reason why EmbeddedCatalinaServiceSX was written to support http and warp connectors, but not Ajp13. I've tried to insert your patch in my environement beside other changes of my own, but I can't find AJP packages in tomcat4.0.1/catalina sources ... what could be the reasons... is ajp support dropped now in tomcat4.0.1 ? stange ? maybe is it hidden somewhere or separate ? I added an initAjpConnector method which takes the default Embedded engine and then substitutes 'Ajp' for 'Warp' for the connector-specific code, and this seems to work Also, Warp doesn't seem to automatically deliver static content to Apache and dynamic content to catalina, although that is a promised feature, and I can't direct it to specifically serve all *.jsp files. what are the symptoms ? normally Apache+mod_webapp should read the static content in the .WAR and not in static files, unlike ajp... (I may have wrongly understood the intended functionalities) Should I be afraid of using Ajp? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] More Scheduler Stuff
-Message d'origine- De: Andreas Schaefer [mailto:[EMAIL PROTECTED]] I will add now the feature to the Scheduler to call a MBean instead of a Schedulable class. This would need two new attributes: - setSchedulableMBean: JMX MBean name - setSchedulableMBeanMethod: method name and what attributes are to pass which can be: - 'Notification' the notification from the Timer - 'Date' date of the call - 'Repetitions' number of the remaining repetitions - 'SchedulerName' MBean name of the Scheduler called - any Datatype like 'java.lang.String' where a NULL will be passed to (which will not work with basic data types) Any other suggestions or remarks ? this seems really cool. The Scheduler is an important tool in an enterprise app... crontab often does the job, but running inside jboss is an advantage One need I had was to call some of my own application EJB from the scheduler. (this would make the application less dependent on jboss, since an external crontab may call an EJB method itself) with your proposed architecture, one would only need to design a MBean that respect the schdulable mbean contract, and then should call a wellknown EJB. here is a discussion about HOW in my opinion an EJB should be called (what's your opinion on that?) : short version: I propose to support 2 kind of MBean to invoke an EJB periodicaly : 1- an MBean that calls a stateless session bean method. - the most simple would be to declare a home/remote interface globally, that the MBean could call, and the business session bean could implement. moreover thing could be easily ported to a n -there should exists a parameters in the MBean indicating wether to queue, ignore or invoke concurently notifications calls that ovelap. 2- an MBean that send a JMS message to a message bean. - message content is not very important, so they will be either empty, constant text (a CDATA ?) or just contain the java.util.Date.toString of the notification date. - session factory and topic/destination will be found in JNDI - if someone want to change the content, either should he derive that MBean, or use a session bean that does the job... long version (arguments...): the most simple would be to call a stateless EJB. whether to reuse the same session bean or to create one each time is a performance and reliability (what if an EJB is undeployed meanwhile) issue. another issue is how to behave if one call takes much time, and if one call overlap another (overlap, queue, ignore)... calling a stateful EJB could seems useful if one want to parametrize the call... but deploying a new stateless session bean with diffrent env-entry does the same and is simpler. (so I think this is not usefull). calling an entity bean could be done for two distinc reasons - to parametrize the notification, with the same opinion as stateful session (ei: not very usefull) - to implement a kind of singleton and control concurent call to the notification method... one could implement this control in the stateless session bean, but as this is a common need, it would be practical to ease that. however my opinion is that the best place to do that is in the notification Mbean, or in the scheduler, that should be configurable to forbide reentry... calling a message bean through JMS could be a nice feature, because message bean invokation are naturally queued, and supports long operations. parameters is not really a problem since there are no essential parameters to be transmited... the mbean could refers to JNDI-stored JMS destinations and factory... for most application sending an empty message to a dedicated message bean, or sending a constant text message to a polyvalent message bean would do the job... sending the date could be useful in some rare cases, where the initial date of notification is important, because calls may be queued for a long time... but anyway if one want to generate complex JMS message one won't avoid writing code, either derivating the MBean, or writing a stateles session bean that send the JMS... for session bean the question could be also wether to depend on a static remote/home interface of to support dynamic calls... if we wan our application to be easily portable to a classic crontab of java thread system, the best would be to avoid dynamic invocation which is not perfect on some J2EE system... does it seems reasonable to you ? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: scheduler bug?
have you read my message about that?
maybe does it not work (possible
since my code is a variant of schedule)
anyway check recent version, and also check the archive in jboss-user or in
the forum, or in jboss-dev
since people here have already answered me that
it was solved...
anyway, you can correct it the DIY way :
if it is the addnotification dynamic call that
fails, check the signature of the addNotification,
and modify the dynamic call so that it
match, the number of arguments, the dynamic
values, and the dynamic types names...
don't forget that basic types have no .class field
(they ar not classes indeed!), but use the .TYPE
fies of the corresponding holding class, eg:
Long.TYPE.getName()
unlike usual
String.class.getName() because String is a class...
also pass the holder type as the dynamic parameters
since the value parameters list is an array of Object,
and basic type are not Object !
depending on the code you have, you should obtain something like
mActualSchedule = ( (Integer) getServer().invoke(
mTimer,
addNotification,
new Object[] {
Schedule,
Scheduler Notification,
null,
new Date( new Date().getTime() + 1000 ),
new Long( mActualSchedulePeriod ),
new Long( mRemainingRepetitions )
},
new String[] {
.getClass().getName(),
.getClass().getName(),
Object.class.getName(),
Date.class.getName(),
Long.TYPE.getName(),
Long.TYPE.getName()
}
) ).intValue();
note that, I repeat, this is not the good mailing list...
this is the jboss internal developers list.
I may even be flammed to death for giving an answer here.
jboss-user was the good one but is officialy (not really)
shut-down
forums on jboss.org are the good place, but to be honnest
I don't read it (an old debate about push/pull
that take place
when jboss-user was shut-down)...
anyway read the archives in forums
-Message d'origine-
De: rajeshwarraov [mailto:[EMAIL PROTECTED]]
Date: vendredi 4 janvier 2002 08:16
À: [EMAIL PROTECTED]
Objet: [JBoss-dev] Re: scheduler bug?
I am also facing same problem...I need the solution
urgently..anybody out there to help me
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: scheduler bug? probably...
I've read the current (latest) 2.4.4
source of the scheduler
this is not the old bug I was talking about, but
another I had forgotten til now, and corrected by the way...
note that it is still present in CVS, in last version 1.4.4.1 of the 2.4.4
branch
and in last 1.12 version of the 3.0* head branch...
summary:
in 2 of the 4 dynamic invocation of the timer addnotification method,
the user object parameter is forgotten...
I've attached a version of Scheduler.java that should work
I've not tested myself (it works on my variant of Scheduler )...
if it correct the problem it should be integrated in 2.4.4 and 3.0 CVS
branch
you can now :
- either:
-make the change according to my hypothesis,
-or take my code if you are confident
- then either :
-compile (with jboss.jar, withou the scheduler*.class), rebuild, and
deploy jboss.jar,
-compile the class, create a jar patch, and refer it in jboss startup
options
-change the package name, compile as usual, make a jar,put it in lib/ext,
and use it instead of org.jboss.util.Scheduler
then if ok, could you tell everybody that it works
(if not, tell me, and if all fails, I'll make my public self-criticism here
8 )
if it works this mail could be a patch proposal to jboss-dev community
(IMHO, a good reason to talk about that here)
hope I'm not wrong,
and hope it will help...
--- long version
I've read the code the addNotification refers
to JMX standard MBean interface Timer.
(could you send me the exact error messages...)
the official signatures of addNotification on
javax.management.timer.Timer
http://dyade.inrialpes.fr/aaa/public/java/jmx/jmx_instr_agent_snmp_javadoc/j
mx/index.html
java.lang.Integer addNotification(java.lang.String type, java.lang.String
message, java.lang.Object userData, java.util.Date date)
java.lang.Integer addNotification(java.lang.String type, java.lang.String
message, java.lang.Object userData, java.util.Date date, long period)
java.lang.Integer addNotification(java.lang.String type, java.lang.String
message, java.lang.Object userData, java.util.Date date, long period, long
nbOccurences)
but in the 3rd and 4th dynamic invocation of addNotification there is no
proposed userData object (which is not used here), despite the fact it is
needed in all version of the addNotification
one should propose a null object as 3rd parameter like it is done in the 1st
and 2nd invocation
you should change the callsto
// Add an initial call
mActualSchedule = ( (Integer) getServer().invoke(
mTimer,
addNotification,
new Object[]
{
Schedule,
Scheduler Notification,
null, /* user object */
mStartDate
},
new String[]
{
String.class.getName(),
String.class.getName(),
Object.class.getName(), /* user object
*/
Date.class.getName(),
}
) ).intValue();
and
// Add regular schedule
mActualSchedule = ( (Integer) getServer().invoke(
mTimer,
addNotification,
new Object[]
{
Schedule,
Scheduler Notification,
null, /* user object */
new Date( new Date().getTime() + 1000 ),
new Long( mActualSchedulePeriod ),
new Long( getRemainingRepetitions() )
},
new String[]
{
.getClass().getName(),
.getClass().getName(),
Object.class.getName(), /* user object
*/
Date.class.getName(),
Long.TYPE.getName(),
Long.TYPE.getName()
}
) ).intValue();
so, get the source of 2.4.4, modify them accordingly,
or use the version I've attached
and then rebuild jboss.jar...
if you don't want to change it
you can :
- get a copy of jboss.jar
- remove Scheduler.class (and Scheduler$SchedulableExample.jar and
Scheduler$Listenr.class) from this jboss.jar
- recompile your version of Scheduler with this jboss.jar
and add the compiled classes to this jboss.jar now, and put it in place of
the former jboss.jar
you can also begin like before with a copy of the jboss.jar, and then
build a scheduler-patch.jar with scheduler.class, ad put them in a patch
directory
that you indicate with the -p option (I've never tested that)
finally the most easy is to copy the Scheduler.java, correct the bug, change
the
package name (eg: package
RE: [JBoss-dev] scheduler bug?
first of all, before beeing flamed, I think
that this list is not the good one for
asking support... it is (as far as I've gerd here)
the list for the jboss developers...
then, I think you have found a bug I've already found,
and that should be corrected now in latest release...
it was something about the dynamic type of the basic long parameters
it works with the dynamic type:
Long.TYPE.getName()
I don't remember what it was before but this
code works for me on 2.4.4. check in the CVS repository since
developers here told be it was corrected...
check my previous mail in the archive also.
mActualSchedule = ( (Integer) getServer().invoke(
mTimer,
addNotification,
new Object[] {
Schedule,
Scheduler Notification,
null,
new Date( new Date().getTime() + 1000 ),
new Long( mActualSchedulePeriod ),
new Long( mRemainingRepetitions )
},
new String[] {
.getClass().getName(),
.getClass().getName(),
Object.class.getName(),
Date.class.getName(),
Long.TYPE.getName(),
Long.TYPE.getName()
}
) ).intValue();
-Message d'origine-
De: Paris Deligiannakis [mailto:[EMAIL PROTECTED]]
Date: mercredi 2 janvier 2002 16:41
À: [EMAIL PROTECTED]
Objet: [JBoss-dev] scheduler bug?
I'm not really sure about this, so please do correct me if
it's wrong or it has been brought up previously:
in Scheduler.java there is this:
[code]
mActualSchedule = ( (Integer) getServer().invoke(
mTimer,
addNotification,
new Object[] {
Schedule,
Scheduler Notification,
mStartDate
},
new String[] {
String.class.getName(),
String.class.getName(),
Date.class.getName(),
}
) ).intValue();
[/code]
However I could not find an addNotification method with only
3 arguments (an object is required before the Date arg).
And when this code runs, it throws this:
[ERROR,Default] javax.management.ReflectionException: The
operation with name addNotification could not be found
regards,
paris
__
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66thread=6463
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] minor Bug in org.jboss.util.Scheduler v2.5.3
I've found a bug in the
call to removeNotification
in the scheduler MBean
the dynamic parameter type is set as int
instead of class Integer...
there are 3 call like these (bug corrected here)
getServer().invoke(
mTimer,
removeNotification,
new Object[] {
new Integer( mActualSchedule )
},
new String[] {
/* Integer.TYPE.getName() */
Integer.class.getName()
}
note that I've found that while building
my own version of this class
that calls a generic session EJB
I'll soon propose it as a
org.jboss.contrib.ejbscheduler.EjbScheduler MBean package...
I've also adapted jboss-iiop/jacorb mbean
to have a a working corba nameservice, with persistent store.
I should adapt it to latest jacorb before publishing.
I've done all of that, because
I'm deploying a demonstation site in my
intranet... it is a portfolio optimization
application, with Jboss/tomcat/jacorb/PostgreSQL/Mico...
congratulation for the job done, thanks for all,
and hope this helps.
--
Alain Coetmeur
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] minor Bug in org.jboss.util.Scheduler v2.4.3
-Message d'origine- De: Andreas Schaefer [mailto:[EMAIL PROTECTED]] Date: lundi 10 décembre 2001 18:50 À: Coetmeur, Alain; [EMAIL PROTECTED] Objet: Re: [JBoss-dev] minor Bug in org.jboss.util.Scheduler v2.5.3 Hi As far as I see these bugs were fixed at 8/14/2001. sorry for the noise I'll soon propose it as a org.jboss.contrib.ejbscheduler.EjbScheduler MBean package... Can you explain which this is necessary ? this came from my own problem : to download data regularily in the database I use... All my data are managed by EJB. si my first solution was to run a java application that connect to the EJB and do the job... then, in the hope to package all in Jboss server, I've tried to play with the JBOSS Scheduler... I did that by adding the ejb-client jar to the MBean path (with the classpath mbean) and call my loader class which calls the EJB. however I've encountered a strange error in the web application ... Jboss failed on a classcast exception in some EJB methods, in the $Proxy. in fact some by value classes (classes that are exchanged with content inside) were exchanged, but the version in the EJB jar and from the MBean global context were different (different classloader I suppose) yet have the same name... all of that could be corrected by separating the interfaces for my loader EJB and the one from all the rest, including the values... However this convinced me to desing something more generic and less tricky for the user : I've created a generic EjbSchedulable remote interface (and a home interface), with e perform(...) method that a user EJB may use . a variant of the Scheduler MBean does a similar job (not the Schedulable interface because of RemoteException), but calls the session EJB that it find through a JNDI name... the application that use this EjbScheduler have only to declare the session EJB and reference the remote/home interface, then add a Mbean descriptor with the JNDI name properly set, beside period and count. We couls alsp use a message EJB, through JMS but I've no knowledge in ejb2.0... maybe useful to serialize the calls. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCMP] W32.Nimda.A@mm worm attack on jbosscmp
I've receives this worm attack (below without the infectious attachments !) through the jbossCMP mailing list. It tries to execute a .exe, when you preview the message, even if you open no attachment at all... please beware this is a well known worm http:[EMAIL PROTECTED] exploiting a Win32/MIME/IE5.x bug corrected by recent patches like this one http://www.microsoft.com/windows/ie/downloads/critical/q299618/default.asp (windowsupdate.com propose it ) hope this helps... victims spread the worm through mail or IIS... -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Date: mardi 18 septembre 2001 18:20 À: undisclosed-recipients Objet: [JBossCMP] usamplesamplesampledesktopdesktopsamplesampledesktopsamplesamplesamplesample desktopsampledesktopsampledesktopdesktopdesktopsamplesampledesktopdesktopsam plesampledesktopsampledesktopdesktopdesktopdesktopdesktopdesktopdesktopdeskt opdesktopsampled -- Virus Warning Message (on the network) readme.exe is removed from here because it contains a virus. - -- Virus Warning Message (on the network) Found virus TROJ_NIMDA.A in file readme.exe The file readme.exe is moved to /etc/iscan/virus/virSIAUdKg3_. For more information, please contact [EMAIL PROTECTED] -
[JBoss-dev] [JBossCMP] W32.Nimda.A@mm worm attack on jbosscmp
I've receives this worm attack (below without the infectious attachments !) through the jbossCMP mailing list. It tries to execute a .exe, when you preview the message, even if you open no attachment at all... please beware this is a well known worm http:[EMAIL PROTECTED] exploiting a Win32/MIME/IE5.x bug corrected by recent patches like this one http://www.microsoft.com/windows/ie/downloads/critical/q299618/default.asp (windowsupdate.com propose it ) hope this helps... victims spread the worm through mail or IIS... -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Date: mardi 18 septembre 2001 18:20 À: undisclosed-recipients Objet: [JBossCMP] usamplesamplesampledesktopdesktopsamplesampledesktopsamplesamplesamplesample desktopsampledesktopsampledesktopdesktopdesktopsamplesampledesktopdesktopsam plesampledesktopsampledesktopdesktopdesktopdesktopdesktopdesktopdesktopdeskt opdesktopsampled ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
