RE: [JBoss-dev] Re: Re[11]: php5 is coming
Hmm.. Just throwing out my 2 coppers, but doesn't the beanshell mbean support allow this to happen easier? You could define the module methods needed and push it out to the deploy dir in a .bsh, jboss hot deploys it, and now its available. James -Original Message- From: julien viet [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 1:05 PM To: Renaud Bruyeron Subject: Re: [JBoss-dev] Re: Re[11]: php5 is coming oh the way is not so important after all, more important is how to map JSP to Nukes components. JSP is one method execution. . modules consist of several methods . theme also but method are well defined by an interface : header(), footer(), etc.. . block the same : renderBlock(), etc... we could map each module invocation to a JSP. theme method to a JSP etc... julien RB julien viet [EMAIL PROTECTED] wrote in message RB news:[EMAIL PROTECTED] JSP are files ** on the disk **, why because java compiler takes files on the disks. clearly nukes stores data in database. that's not incompatible I know. RB Two remarks: RB 1) have you looked at eclipse's JDT? it *might* be able to compile RB resources that are not on disk... not sure, I've never looked at RB it... RB 2) it seems that what you really want is a templating language like RB velocity... velocity is fastsimple. oh, and this might be RB interesting: RB http://jakarta.apache.org/velocity/developer-guide.html#Config uring% RB 20Resour RB ce%20Loaders RB $0.02 RB - Renaud RB --- RB This SF.net email is sponsored by: ValueWeb: RB Dedicated Hosting for just $79/mo with 500 GB of bandwidth! RB No other company gives more support or power for your dedicated server RB http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ RB ___ RB Jboss-development mailing list RB [EMAIL PROTECTED] RB https://lists.sourceforge.net/lists/listinfo/jboss-development -- Best regards, julienmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] NUKES on JBoss
-Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2003 1:16 PM To: JBoss Dev Subject: Re: [JBoss-dev] NUKES on JBoss I'm sure they did do some testing... I'm sure they did, and it's a great improvement over the PHP version. But, I'd say some time hosting it at beta.jboss.org or something would have been a good thing (TM) and still give us a chance to pound out the last of the nastiness. Just a thought in hindsight. Thanks Julien, et. al. for all the hard work! James --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [OT] Eclipse is so amazing...
Jason, I'm in the same boat.. Been using Emacs + JDE for years, but Eclipse is starting to supercede.. I actually posted a message to the JDE user list regarding this. But, alas, eclipse is so stupid, it can't open a file outside of a project and can't talk SSH2 natively, so it has to shell out ssh/cvs calls.. But, it looks as if I'll run with both, then migrate to Eclipse soon.. Its just too slick.. James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 12:00 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Eclipse is so amazing... I can not believe how fast, intelligent and functional this little IDE. I have tears in my eyes I am so pleased. Okay perhaps I need to get out more... but still. I think I am going to have to say goodbye to XEmacs. Perhaps I am just getting old and lazy... --jason --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JNuke dev
Julien, snip Makes sense so far 3.PostNuke is all about invoking module functions. Url like index.php?module=Userop=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). So, how would you pass arguments from the request to the method in the module mbean? Do you plan to just have each method take a hashmap that you have constructed from the request? Knowing that modules may need arguments for performing work, like a URL to an RSS feed or something. Thanks, James --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JNuke dev
I remember a few months ago that some people were talking about writing a killer jboss app to prove what could be done with the server. Let Julien write it the way he prefers, using all Jboss capabilities first. The nice thing is that open source allows someone to take it and make it fully j2ee 1.3 compliant if they want, and reciprocate the code back.. Let Jboss shine! Go Julien Go! James -Original Message- From: Nathan Phelps [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 1:48 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev I would think that we'd want to make this a J2EE application so it can run on ANY J2EE application server. Therefore, I would elect to go down a pure J2EE route instead of a JBoss only JMX route. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ben Sabrin Sent: Tuesday, January 14, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev Are we developing this for the PHP community or the Java community? Or more important for the JBoss community? To me it seems that it would depend on who you are targeting for your user base. If you want to target the PHP users to bring them to JBoss, then Bill could be right. If we do not care about the PHP community, we go down the JMX way. I think the PHP community will never want to do anything with JSP. They believe they have what they need to be successful and will continue to innovate in their own circle. For most of the PHP community, what they have built is scalable to their needs. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 1:51 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be dumbed-down for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 11:31 AM To: SourceForge.net Subject: [JBoss-dev] JNuke dev hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=Userop=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First
RE: [JBoss-dev] My fuck up
You guys thought of doing: wget --recursive http://www.jboss.org, publish the static files every 15 min, and only use the PHP for processing submission forms? Just a thought to quickly reduce your PHP dependence except for new forum posts.. Dunno if you would have to pipe each file to a sed script or something for some fine tuning, but that may be faster than waiting for Jnuke to be completed, functionally tested, and load tested.. Or, I guess you could rollback the old website and update the links to reflect 3.0.5, right? James -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:54 PM To: Jboss-Development@Lists. Sourceforge. Net Cc: 'JBoss Group' Subject: [JBoss-dev] My fuck up I got nuked by postnuke. The stuff just doesn't scale. Either that or we are doing something really wrong. In any case the site is UN-USABLE. We will continue with our port of postnuke and see if we can come with a real forums/nukes on jboss project. My bad. I make mistakes, I should have tested this under heavier load, PHP plain doesn't work as is. We will get the website back to its former state. Bear with us. A humbler, marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] My fuck up
Do we need to start a counseling fund for Julien after all the written by a 12-year-old PHP that will have to be seen, reversed, and cried over? -Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 8:25 PM To: JBoss Dev; marc fleury Subject: Re: [JBoss-dev] My fuck up Just think of this as an opportunity to write a really good case study on the advantages of J2EE/EJB/Caches. From: marc fleury [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Mon, 13 Jan 2003 17:53:48 -0500 To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Cc: 'JBoss Group' [EMAIL PROTECTED] Subject: [JBoss-dev] My fuck up I got nuked by postnuke. The stuff just doesn't scale. Either that or we are doing something really wrong. In any case the site is UN-USABLE. We will continue with our port of postnuke and see if we can come with a real forums/nukes on jboss project. My bad. I make mistakes, I should have tested this under heavier load, PHP plain doesn't work as is. We will get the website back to its former state. Bear with us. A humbler, marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
Funny, I was just doing research for a CMS that offers webdav access,
versioning, workflow, etc. as you find in most real CMSs (not those
incessent fake ones)..
I was about this close {index fingers almost touching} to going with
Post-Nuke.. My reasons not to? Well, most of the people that would help
me were Java guys.. PHP is easy, but why change? Also, the fact that
there is some warring and branching going on, so extending it would be a
political nightmare to weed through (nice - I like this extension -
what?? It only supports the Bob branch!!). Finally, the code for PHP is
always a pain, so integrating new functionality is sometimes more
painful than just writing it yourself.. That shouldn't be the case, but
that's PHP - hack first, never clean it later..
I for one would love to see a JNuke.. Viet, do you have a sourceforge
project started for this or anything, so we can help out? I'm really in
need of a portal hosting (ala sourceforge) solution, but a single
content portal ala Post-Nuke would be a great start..
BTW, I finally settled on Jakarta Slide (WebDAV, versioning) and a
custom workflow component (OSWorkflow has too many problems with their
volunteers and too much buy in for their framework of doom). I just need
a good client now, which I'll probably use an OSS one and rewrite over
time as the user's needs change.
James
-Original Message-
From: Matt Munz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 1:22 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] PHP
Bill,
Don't worry, I'm not going to blast you for not eating your
own dog food.
JSP/Servlets/J2EE is better, but PostNuke is a good Content
Management
System.
This statement, in and of itself, is a rationale for using
J2EE instead of PHP ;) Could you divulge the precise
reason(s) for choosing Post-Nuke? (I can think of many
factors that often outweigh technical superiority -- time,
money, expedience, IP issues... was it one of these?)
We're gonna call it JNuke
sounds interesting...
- Matt
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 1:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] PHP
new website. Its PHP and PostNuke. Its OK.
JSP/Servlets/J2EE is better, but PostNuke is a good Content
Management System. Julien Viet is looking into porting it to
the Java world. We're gonna call it JNuke.
Bill Burke
Chief Architect
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Matt Munz
Sent: Thursday, January 09, 2003 1:38 PM
To: JBoss Developers Group (E-mail)
Subject: [JBoss-dev] PHP
Hi all,
I just noticed that many of the pages on the website end
in .php.
Has it always been this way, or is it new? I'd be very
interested in
hearing the rationale for using PHP over a servlet-based or other
solution. I'm not all-to familiar with PHP, but I'm seeing
it a lot
lately...
- Matt
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something
2 See! http://www.vasoftware.com
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2
See! http://www.vasoftware.com
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[6]: [JBoss-dev] PHP
What about just writing a shell script to walk the tree of jboss.org via the PHP every x min or hours, spit out static HTML, and only offer paths to the PHP-based pages for POSTing of new forum stuff? Would that be a bit faster and reduce your server load at the PHP end for read-only stuff, before Julien gets everything ported for the long term solution? Just being creative here.. James --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD
I wonder if it would be possible to put the .bsh in a .sar in your .ear? Not sure, haven't tried it.. And agreed, this bsh support really is interesting.. -Original Message- From: Adam Heath [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 11:52 AM To: Jboss-Dev Cc: jBoss-User Mailing List; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD On Tue, 7 Jan 2003, Sacha Labourey wrote: Hello, Yesterday I commited a BeanShell (BSH, www.beanshell.org) sub-deployer in HEAD. It is in module varia and you can find its lib in varia/output/lib/bsh-deployer.sar. It allows you to hot-deploy *.bsh files in /deploy. [snip] /me goes looking for a towel, as his monitor just got all sticky. This is EXTREMELY cool. We can now support upgrades of whatever, which means fixing databases(adding/remove fields, fixing data), and various other things. If something like this could also be added to J2EE deployments(in META-INF dirs), then I'd be even more excited. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD
Sounds very interesting.. I wonder how it might help to integrate Jboss
and Emacs/JDEE, since they use the bsh to perform Lisp-Java
integration..
James
-Original Message-
From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 3:57 AM
To: Jboss-Dev
Cc: jBoss-User Mailing List; [EMAIL PROTECTED]
Subject: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD
Hello,
Yesterday I commited a BeanShell (BSH, www.beanshell.org)
sub-deployer in HEAD. It is in module varia and you can find
its lib in varia/output/lib/bsh-deployer.sar.
It allows you to hot-deploy *.bsh files in /deploy.
SIMPLE USAGE: client-only
=
In its simple usage, the script will act as a simple
client-script making invocations on other objects. Each
script can follow the org.jboss.system.Service interface i.e.
the create, start, stop and destroy calls. You can implement
only a subset of those. Thus, a very simply one-line script
can be: Simple.bsh:
void start() { System.out.println (I'm called!); }
that's it.
ADVANCED USAGE: server script!
==
But it is almost as easy to make your script a JBoss service
fully invocable/administrable through JMX! For this, your
script can implement any of the methods of the following interface:
public interface ScriptService
extends org.jboss.system.Service
{
public String objectName ();
public String[] dependsOn ();
public Class[] getInterfaces ();
public void setCtx (ServiceMBeanSupport wrapper);
}
You can implement the objectName method to choose your own
MBean ObjectName. You can implement the dependsOn method to
return a set of JMX MBean ObjectName (as string) on which you
depends (for service lifecyle). You can implement the
getInterfaces method to return the set of interfaces that you
*say* your script do implement. Your wrapper will analyse
these interfaces and fully generate the associated JMX
MBeanInfo (the script wrapper is a Dynamic MBean).
Example, let's say you have this interface:
public interface MyIntf
{
public void doThat();
public String getRWString ();
public void setRWString (String val);
public String getROString ();
}
You could then provide this script:
String name = bla;
String objectName () { return jboss.scripts:service=myService; }
Class[] getInterfaces () { return new Class[] {MyIntf.class}; }
void create () { System.out.println (Create called on me); }
void doThat () { System.out.println (doThat called); }
String getRWString() { return super.name; }
void setRWString(String bla) { super.name = bla; }
String getROString() { return I am read-only!; }
Then, not only can you invoke methods and get/set attributes
on your script using JMX, you can also browse your scripts
using the http://localhost:8080/jmx-console/ and see all
available methods/attributes (MBeanInfo is generated by the
DynamicMBean script wrapper)
Infos on BeanShell are available here: www.beanshell.org
Do you want this feature on 3.2?
Cheers,
Sacha
P.S.: This e-mail is cross-posted to the beanshell-users ML.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something
2 See! http://www.vasoftware.com
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jboss + Junit?
Title: Jboss + Junit? Hi, I wanted to drop this note on the dev list since this question is in regards to a previous posting on the dev list. I had heard that the jboss team had made some extensions to Junit, is that right? If so, what were they in a nutshell? Can someone point me to the source as well? Also, does anyone know if there is a project out that provides Junit as an mbean such that unit tests can be deployed and run within the jboss runtime and test local EJB methods, utilize hot deploy (like the junit custom classloader concept), etc? I was just wondering if anyone had considered such a thing, knowing full well that it would be a JB only thing and that more cross-server solutions have been made (Cactus for one). It seems to be that it would be a more beneficial solution - write, compile, deploy, test within one VM in theory, possibly kicked off from the beanshell in Emacs (David should like that one!). Ok, so I'm dreaming a little.. Thoughts? James
RE: [JBoss-dev] Jboss + Junit?
Title: Message Bill, Thanks for the tip, this is some interesting stuff.. I was thinking of taking it one step further and constructing a TestRunner that is really an mbean. So, you could in fact deploy your ear, a jar with the unit tests, then through the console run a single class's tests.. I haven't quite figured out how to run more than one without writing either a custom deployer and use some extension like .junit for the jar of test class(es) or having the mbean querying the respository and finding all *Test classes deployed. This way, the test can actually be on the server side and invoke local methods. You could also hot deploy your ear and your unit tests and run them again without shutting down. Thoughts? Is this in there and I just missed it? Or, do I just have way too much time to think about applications of JBoss? I'm just tired of the same ol' J2EE applications I guess I really like the JBossTestSetup and assoc classes - really nice! James -Original Message-From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 5:08 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] Jboss + Junit? Our Junit extensions support all of what you want. Its under testsuite/... We need somebody to document this stuff. Somebody volunteered once, but never got back to me. Bill -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James HigginbothamSent: Thursday, January 02, 2003 4:23 PMTo: [EMAIL PROTECTED]Subject: [JBoss-dev] Jboss + Junit? Hi, I wanted to drop this note on the dev list since this question is in regards to a previous posting on the dev list. I had heard that the jboss team had made some extensions to Junit, is that right? If so, what were they in a nutshell? Can someone point me to the source as well? Also, does anyone know if there is a project out that provides Junit as an mbean such that unit tests can be deployed and run within the jboss runtime and test local EJB methods, utilize hot deploy (like the junit custom classloader concept), etc? I was just wondering if anyone had considered such a thing, knowing full well that it would be a JB only thing and that more cross-server solutions have been made (Cactus for one). It seems to be that it would be a more beneficial solution - write, compile, deploy, test within one VM in theory, possibly kicked off from the beanshell in Emacs (David should like that one!). Ok, so I'm dreaming a little.. Thoughts? James
RE: [JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
Funny, I was thinking about this concept the other day, as I still have delusions of grandjeur to build a rich client application on top of the Jboss kernel. My thoughts on this were along the lines of the following, based on a scenario of an upgraded component version (discovered via some mechanism ala JNLP): 1) Module is downloaded into a temporary local location 2) Existing module is unloaded by removing it from the JMX container 2a) All dependent modules are therefore disabled until this removed module is back online 3) Current module is copied to a backup location for restoration if the new version needs to be reverted 4) New module is installed by copying it into the deploy directory 4a) All dependent modules are back on since their dependency is now available again with the new version Outstanding questions: 1) Should a CVS/RCS-like versioning be done locally to enable multiple revision restoration in case of incompatible modules 2) How to handle versioning requirements between components (i.e. I install a new foo v1.1, which requires the Commons 1.1 lib and v. 1.4 of the Bar module as well) Just some thoughts to get the discussion going. Is you considering making all Eclipse plugins Mbeans now, or just a specific part of the platform Mbean based? Regards, James -Original Message- From: Matt Munz [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 22, 2002 10:46 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted) Christophe, Well, I'm not aware of a doc that refers to loading/unloading specifically. JMX is a specification that focuses on instrumentation of networked components, and it, like many Java Specifications, has a limited focus, with few implementation details described in the specification. It has noetheless become apparent to some that JMX is useful as a backbone for a modular plugin architecture. I'm copying the JBoss development list on this thread, as there are a lot of JMX implementors there that could give more insight on the loading/unloading mechanism. Perhaps one of them knows about a concise document that explains the process? You might be interested in the following short description of JBoss/JMX which mentions classloading. The book mentioned on this page is also an excellent resource. http://jboss.org/developers/projects/jboss/jbossmx.jsp A more lengthy (but helpful) read is the JMX Specification itself. http://java.sun.com/products/JavaManagement/download.html The following developerworks articles don't really discuss loading, but I found them useful in evaluating JMX. http://www-106.ibm.com/developerworks/java/library/j-jmx1/ The reason I think of JBoss/JMX is its deploy folder. Drop in a module, and the server loads it automagically. Delete the module, and the server unloads it. Everything is configured with XML. It seems to me that this might be where Eclipse wants to go in terms of dynamic loading/unloading. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Fri 12/20/2002 4:03 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted Ed, I see the following item in the list: Allow plug-in deactivation. Not sure how far we can go Matt, Can you point us to some short-concise JMX doc about loading/unloading ? I want to know how far the Update Manager can reuse some of the techniques Christophe Elek Eclipse Platform - IBM Toronto Lab. (905) 413-3467 Friday, December 20, 2002 4:09 PM To: [EMAIL PROTECTED] cc: From: Matt Munz [EMAIL PROTECTED] Subject: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted Ed eclipse-dev, One item that I think should be on the 2.2 plan is dynamic loading and unloading of Eclipse plugins... Is there any interest in using Java Management eXtensions and/or the JBoss microkernel for this purpose? It seems to me that the differences between server-side dynamic module loading and client side dynamic module loading are few, if any. Based on my experience with Eclipse and JBoss I see a lot of similarities in architecture and approach. JMX is also generally gaining acceptance, and comes with a lot of useful features beyond dynamic loading. - Matt -Original Message- From: Ed Burnette [mailto:[EMAIL PROTECTED]] Sent:
RE: [JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
How much of what you are thinking of would be handled by: jmx Most if not all of it - the JMX timer would be responsible for the async work of taking down and upgrading the module and its dependencies. In addition, the rich client platform would benefit from JMX itself. The only problem is transports between rich clients, but that is out of scope for long enough that the JMX spec should catch up anyway. Besides, JXTA could handle that if I really needed peer-to-peer rather than a more client-server approach. Or, I could just use your built-in clustering using JavaGroups as another option. jboss service lifecycle All of it, as I would see a module as the equiv of an EJB on the client side from the standpoint of componentized development and the need for component lifecycles. I actually built a similar application that was Swing-based, used JXTA, and resembled something like Groove.. We called it our Groove Killer but never got enough $$ after 9-11 to launch it full scale. I'd like to rewrite the framework I built our product on using Jboss and open source it. Something like Eclipse but not so IDE-centric in focus. Anyway, it modeled the EJB lifecycle for the modules and provided a Module context for accessing known platform services, plus a service locator for a more dynamic lookup (including web services on the desktop over JXTA - that was fun!). jboss mbean dependencies enhanced by including the version as a key in the ObjectName and using queries or filter conditions rather than equality for resolution of dependencies. Jboss dependencies would be a must. I hadn't thought about versioning in the name.. In the past I've shyed away from things like that in a name, but since its unique to the JMX container, that should be fine.. Like encoding the version number in a OID I guess. BTW in jboss 4 clients using the trunk invoker already have jmx client side: others will follow when I get to work on tx propagation for the other transports. True, but I would want the JMX container initialized first thing.. Consider the typical startup as something like splash, init Jboss Kernel, Load core platform services, load user services, launch user application. david jencks James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky
Jules, Um... I hate to say this, but I think Weblogic works around this - it defaults to nio and backs off to its older non-nio.. They used to call it their performance pack before 1.4, and have since just swapped theirs for nio I think.. You said it was a static config, but I don't see why you can't abstract out the strategy, and back off to the default strategy if nio isn't available. Just a thought, and may sound simpler than the impl, not sure.. I haven't looked a the Jetty codebase in a while.. James -Original Message- From: Jules Gosnell [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:34 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jetty NIO SL in JBoss 3.0.4 no worky Peter Fagerlund wrote: torsdagen den 21 november 2002 kl 11.46 skrev Jason Dillon: Fuck... how can we make one build work for both? Use a runtime switch ... 1. Jetty's config is static - I could work around it 2. You would need to build to the LCD (1.3) and then do another build for optional 1.4 components... Or - we just live with it until we can force a move to 1.4, of course then we will have the same problem with 1.5... Software huh ! Jules --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com __ __ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
Is this ala the Weblogic central config file, or just a secondary file created as the kernel accepts new components and started from scratch on each startup (I hope)? -Original Message- From: Bill Burke [mailto:bill;jboss.org] Sent: Wednesday, November 13, 2002 11:08 AM To: Jboss-Dev Subject: [JBoss-dev] Metadata Service Dain and I were IMing. He said Scott was thinking about a MetaData service... My idea for a MetaData/Configuration service would be the ability to register for callbacks based on XPATHS. So, all config of jboss would be stored in one big XML Document. Components insert their config there, and register for callbacks on this config via XPATHS. So, this config can be managed centrally, yet, components can easily be notified with changes via a simple mechanism. Bill --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
Scott, Interesting.. Do you have this scoped in your mind yet? I mean, Jboss (I hate how outlook fixes the b in jboss) currently uses JavaGroups, which assumes a multicast-enabled network. When you get to true peer-to-peer, you may have a double firewall situation where multicast doesn't work outside your LAN. In which case, you need concepts of superpeers on your local network that all register with public directory services to create a web of superpeers bridging private networks. This is (sortof) what JXTA does best (cough). In the past, I've seen discussions of JXTA + Jboss but haven't seen many thoughtful proposals, just it would be cool ifs. Am I taking this vision of yours too far, not far enough, or missing you completely? The architecture of your dynamic proxies and JavaGroup networking seems to work great for local networks, so you must be envisioning more? James -Original Message- From: Scott M Stark [mailto:scottmstark;attbi.com] Sent: Saturday, November 09, 2002 12:54 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? A JMX microkernel on the client is an avenue to explore. The focus should be extending the current dynamic proxy and detached invokers to a kernel for peer-peer type of computing: agents, grid computing, JMS, RMI callbacks, distributed caches, and whatever P2P is going by these days. To me the extension is one of a client simply downloading smart proxies to downloading a microkernel whose base configuration is defined by the server, extensible by the client, and capable of offering services for peer-peer computing. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 9:10 AM Subject: Re: [JBoss-dev] JMX on the client side? Matt Munz wrote: What's wrong with mbeanServer().registerMBean(mmb, name) ? Thank you matt. That is exactly what I am thinking. The first time you lookup an EJB or JMS connection, we we lazily force the client side to have an MBeanServer. Then we register only the mbeans required to service that object. For an EJB that may mean just a light weight client side container and a cache MBean. For JMS we would register a client side container and a reverse invoker. I'm not talking about anything heavy weight. I still want this to be able to run on a cellphone. If the programmer decides that they want a heavier solution they can start an MBean server a startup with a sar deployer. I guess I'm thinking that some clients will not want to get overly involved with the file system. Like applets. JMX on the client side and JBoss on the client side are two different things, right? AFAIK, MBeanServerFactory.createMBeanServer() doesn't require the service deployer. If it does, that's another thing... Agreed. All I am talking about is an MBean server. If someone wants more JBoss services on the client side they can do that, but it shouldn't be required. -dain --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
Interesting.. Are you guys talking about a small JMX container on the client invoker side? Or something else? -Original Message- From: David Jencks [mailto:davidjencks;directvinternet.com] Sent: Thursday, November 07, 2002 10:12 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? +1000 This will greatly simplify many things, such as the trunk invoker client. I'd like to suggest that we also consider basing UserTransaction on a transaction manager instance on the client: this would allow UserTransaction to use the same propagation mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult. david jencks On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: Why don't we require jmx on the client side? I bet it takes almost no memory and it has a small jar size. If do require it on the client side, we can reuse all the services we are building on the server, like a jcache mbean. It would also simply server to client messages, which will be used for cache invalidations and jms messages. This is because we can reuse the invoker architecture. There will still be a problem with socket back channels to clients on the other side of a firewall, but we would get a ton of reuse and simplification. -dain --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
That would be interesting. I've really wanted to put together a rich client framework using jboss as the kernel for adding services and hotdeploying client functionality, but haven't had the time. Just something to think about: what happens if you do this and I want my app to start a kernel - what sort of classloader implications are there - could I end up with 2 kernels in the same VM? Just a thought.. This would rock! James -Original Message- From: Dain Sundstrom [mailto:dain;daingroup.com] Sent: Friday, November 08, 2002 11:25 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? Yes that is exactly what I am suggesting. When you first contact the JBoss server we start an MBeanServer if non is available. I think we may have problems if we use features specific to the JBoss JMX code (like not having huge bugs), but that is a discussion for another day. -dain James Higginbotham wrote: Interesting.. Are you guys talking about a small JMX container on the client invoker side? Or something else? -Original Message- From: David Jencks [mailto:davidjencks;directvinternet.com] Sent: Thursday, November 07, 2002 10:12 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMX on the client side? +1000 This will greatly simplify many things, such as the trunk invoker client. I'd like to suggest that we also consider basing UserTransaction on a transaction manager instance on the client: this would allow UserTransaction to use the same propagation mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult. david jencks On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: Why don't we require jmx on the client side? I bet it takes almost no memory and it has a small jar size. If do require it on the client side, we can reuse all the services we are building on the server, like a jcache mbean. It would also simply server to client messages, which will be used for cache invalidations and jms messages. This is because we can reuse the invoker architecture. There will still be a problem with socket back channels to clients on the other side of a firewall, but we would get a ton of reuse and simplification. -dain --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
I think James had more esoteric plans... -danch Right.. I'm not talking about Jboss proper, I'm speaking of a rich client platform that uses jboss as its service arch kernel. Imagine a world where jboss is installed everywhere - client and server. ;) James --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [OT] JMX on the client side?
Well, I'm not really talking that, though I did address that in a JXTA product I architected around May of 2001 - we never went public with it, as we decided not to try for funding after Sept 11th - customers for it would be few and far between with RD budgets gone.. I'm speaking more of using Jboss and its JMX capabilities to design what I would call J2DE - Desktop edition. Something that encompasses a service-oriented architecture, with things similar to EJBs or Jboss JMX services that are plugged in to extend the capability of a rich client. No, not swing from an mbean on a server (re: a past post), but the inverse. Kinda like the BeanContext API sun packaged but never really explored fully.. A service component that has a context to its gui container and the services to which it may have access to. So, yes, some services may be a lightweight proxy to a web service, with the option of installing the .sar locally if you tend to use it a lot. Make sense? Sorry for this on the jboss-dev list. We can take this offline for anyone else interested in this further. Dain's email got me thinking that his idea of a JMX container on the calling client could be cool, but could also introduce some technical issues for what I was thinking. My apologies for taking jboss-dev's time on this one.. James -Original Message- From: Matt Munz [mailto:mmunz;apelon.com] Sent: Friday, November 08, 2002 4:36 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JMX on the client side? Imagine a world where jboss is installed everywhere - client and server. ;) You're talking about (more evenly) distributed systems (a.k.a. P2P)? I think you're still going to need a delineation of roles -- some nodes are going to be thicker than others. You don't want to start up an entire JBoss stack just to run JNotepad (fictional). Likewise, I'd imagine you don't want all of your client side applications running in the same JVM. It seems to me that a measure of fault tolerance is worth the extra memory use (by starting up separate VMs) in this case (although I'm interested in arguments to the contrary). It seems to me that when you're designing a node in a distributed system, you start out by defining the role/functionality. Then take the most minimal JBoss kernel. Then start stacking on functionality until you have what you want. What makes this better than client-server, IMO, is that all nodes (should) share a common architecture. That way, server-side code can easily be pushed to the client for added performance. So JNotepad uses a Web-service based remote spellchecker. You like it? OK, download spellchecker.sar, and any server modules that it depends on. What makes this worse than client-server is that it doesn't exist yet, AFAIK :) ... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of James Higginbotham Sent: Friday, November 08, 2002 4:42 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JMX on the client side? I think James had more esoteric plans... -danch Right.. I'm not talking about Jboss proper, I'm speaking of a rich client platform that uses jboss as its service arch kernel. Imagine a world where jboss is installed everywhere - client and server. ;) James --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX on the client side?
JBoss Unlimited. JBoss Unleashed. Infinite JBoss. This is the kind of thing that makes suits giddy with joy. Right! Or: JBoss Web Service Platform JBoss: Web Service Edition JBossXML In fact, if you change the tagline from WebOS to WebServiceOS, you can charge more consulting bucks on your engagements! ;) Have a great weekend everyone! --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Upcoming releases
Scott, Can you or someone on the team tell me which version I should upgrade our product to - 3.0.x or 3.2? I'm about to move from 3.0.0 and want to make sure I'm on the right branch to make migration to 4.0 easier in the future while remaining stable for our product release that will occur by the EOY. Thanks, James -Original Message- From: Scott M Stark [mailto:scottmstark;attbi.com] Sent: Wednesday, November 06, 2002 8:17 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Upcoming releases Go ahead. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 1:09 PM Subject: Re: [JBoss-dev] Upcoming releases What has happened to the 3.2beta release ? I have some stuff to put in - am I to late ? Jules Scott M Stark wrote: I'm planning on the following releases so time your work accordingly: 2002-10-25jboss-2.4.10 2002-10-27jboss-3.0.4 2002-11-03jboss-3.0.2beta2 2002-12-22jboss-4.0alpha Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Upcoming releases
I am reading this right, 2 comes after 4?: 2002-10-25jboss-2.4.10 2002-10-27jboss-3.0.4 2002-11-03jboss-3.0.2beta2 ^ 2002-12-22jboss-4.0alpha --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JBoss-user] capacity planning to use jboss
Bill, This is interesting about not using clustering.. Are you guys using CMP at all? If so, how do you suggest synching the entity beans without using clustering? On a site without CMP, you can usually get away from clustering, but wondering if you have used the equiv of Javelin to do distributed caching, deployed the CMPs a specific way, or just depend on pessimistic locking and the DB vendor. Thanks, James -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:47 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JBoss-user] capacity planning to use jboss - You'll probably want to buy some Hardware based HTTP load-balancer for your web traffic. Make sure it supports sticky sessions. You can try Apache + modjk + AJP13 if you want a cheap software solution. Jetty and Tomcat can be hooked in. - Do you require HTTP Session replication and failover? If its ok for a user to relogin after a failover, I suggest not using JBoss clustering features at all, (Except for net boot and maybe farming). - On the performance tests I ran(ECPERF), replication had a 10% hit on performance for 2 boxes running in a cluster. You'll probably have more than 2 boxes(but not much more). - I suggest marrying the WEB and EJB layer into one JVM/process. You'll get better performance. - Next what you have to do is guess peak traffic. Multiply that number by 2 just to be safe. - Next you'll need to write a stress test program - Next you'll need to hire JBossGroup to help you out with all of this. :) - Next you'll need to purchase a high quality support contract from JBossGroup to iron out any problems you may have :) At Mercantec we had 2 dual 900mhz CPU running Linux and JBoss, 1 dual 900Mgz PIII running Oracle. We could support traffic from 10K merchants. But that's our application. How many users your app can support on a given piece of hardware is totally dependent on the type of application you're running. DON'T USE CLUSTERING UNLESS YOU HAVE TO! Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Emerson Cargnin - SICREDI Serviços Sent: Wednesday, October 16, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [JBoss-user] capacity planning to use jboss Today i got a question from my manager (i work in a bank, there will be a web layer at the bank office and a central ejb layer) : Emerson, how many boxes in the ejblayer do we need to support 800 offices and more than 4000 simultaneous clients (from the offices). Imagine that you have available any number of xeon dual 2mhz with 2giga RAM connected through a gigabit lan, how many boxes of this kind do we need? I confess that i exitated a little. This is a though question, indeed. I think that CMP and mainly clustering will not have the same gain when you have too many nodes in the cluster, given the communication needed among the nodes to keep the data replicated. Does any one have any parameter for a capacity plan for a scenario like this? jboss group, any clue ?? What could be the limit beetwen number of nodes and replication overhead? Thanks in advance for any answer : ) -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308; v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored
RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j
No, other than just watching the commons mailing list recently. I'll check on it, though Scott doesn't want to switch so it will be FYI research only, I suppose. James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 8:24 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j It is too bad commons logging does not provide abstractions for a ContextStack or ContextMap similar to Log4j's NDC and MDC. These are valuable constructs. Do you know anyone on the commons logging team? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of James Higginbotham Sent: Friday, October 04, 2002 6:41 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j Do you know how you switch the LogFactory impl? I am guessing there is a system property, but I did not see anything obvious by looking at the javadocs. I've been using commons logging for a few months now - not bad at all.. You drive the impl from a properties file called commons-logging, like so: org.apache.commons.logging.Log=org.apache.commons.logging.impl .SimpleLog If you put in log4j, just put the log4j properties or xml file in the classpath so log4j can initialize when needed. The nice thing about using this API is that they have done the factory work for you, allowing jboss clients to use the simplelog they provide, a null log, jdk1.4 (ugh), or whatever. Sure, you have that abstraction, but do you really want to do the simple factory work? Probably not, as you guys have more important things to do ;) James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Over zealous deployers
However, I did modify the ear deployer to only deploy those archives mentioned in application.xml. Unless this has been modified since, ear files are not searched for deployable entities (although jar, sar, rar, ... archives are). Actually, this brings up a question I've meant to ask for a while - how do you guys determine the order for which modules are deployed when declared in an application.xml file? I had asked a few days ago how to control the order of deployment of ears and wars (currently separate in the deploy dir). But, without changing my deploy scripts in Ant, I wanted to see what the algorithm was (or where the code lives) that determines the order. I was thinking that if the war was defined last in the application.xml, it might get deployed last and thus my cheezy, x-appserver SessionContextListener would fire after all EJBs are deployed (Mbeans are out, as I don't have good mbean support in the jboss foe servers). Thanks, James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Over zealous deployers
OK, thanks for the info. I hope to at least implement a soltuon using a deploy order implementation (a solution from Sacha, thanks!) that simply adds the war filter after the ear, and see if I have another solution in the foe servers. Sounds like the apache commons digester or Castor *might* help with that random issue, since they use SAX (and may then fire the events in order of the XML rather than produce a random list) to call the digester rules. Since it's a one-way read, it may offer an ordered deployment, but can't recall if the specs say that this is required or not and if I'm right about those 3rd party libs or not (I'm tired and lazy to find out right now). If its not a spec requirement, then I'm sure this isn't a priority and I don't have a chance of getting a x-server solution through the application.xml anyway. Thanks again, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 05, 2002 9:33 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Over zealous deployers Again, I am not positive, but I believe the order is determined by the XML impl, when it returns a NodeList. From what I can tell the order is fairly random. The only way I could get deployments to order correctlt was to use the JBoss depends tag (in jboss.xml in each of the members of the EAR) and depend on the dependent deployed services in the other JAR files. --jason Actually, this brings up a question I've meant to ask for a while - how do you guys determine the order for which modules are deployed when declared in an application.xml file? I had asked a few days ago how to control the order of deployment of ears and wars (currently separate in the deploy dir). But, without changing my deploy scripts in Ant, I wanted to see what the algorithm was (or where the code lives) that determines the order. I was thinking that if the war was defined last in the application.xml, it might get deployed last and thus my cheezy, x-appserver SessionContextListener would fire after all EJBs are deployed (Mbeans are out, as I don't have good mbean support in the jboss foe servers). Thanks, James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j
Do you know how you switch the LogFactory impl? I am guessing there is a system property, but I did not see anything obvious by looking at the javadocs. I've been using commons logging for a few months now - not bad at all.. You drive the impl from a properties file called commons-logging, like so: org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog If you put in log4j, just put the log4j properties or xml file in the classpath so log4j can initialize when needed. The nice thing about using this API is that they have done the factory work for you, allowing jboss clients to use the simplelog they provide, a null log, jdk1.4 (ugh), or whatever. Sure, you have that abstraction, but do you really want to do the simple factory work? Probably not, as you guys have more important things to do ;) James --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Build System... any ideas
Jason, I had submitted an example directly to David sometime last week, but I'll share with the world now so that the entire Jboss team can benefit. Its not a Java project per se, as it really only uses a sitemap.xml and an XSL to produce another ant script for running XSL transformations on a web site I manage. But, you are welcome to use it as a starting point. I was hoping to convert a project that I am managing from using redundant task bodies to use something like (half-baked mind you): module name=Foo depends module name=Bar/ /depends libs lib ref=my.class.path.ref /libs ear/ war/ java/ xdoclet/ /module But for now, take a look at the following project for an example of using XSL + XML to produce dynamic Ant scripts. Not sure if it will help, but see if it will get you started. I can answer any questions you have about how it works, as I am fluent in XSL. cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin co ccaustin The interesting files are the src/web/xml/sitemap.xml , src/web/xml/sitemap-build.xsl, and if you run the ant script with an XSL engine in your $ANT_HOME/lib, it will produce a file called autogen-build.xml in src/web/xml HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 9:26 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas If I send you an example .xml file can you send me a basic skeleton stylesheet with examples on how to replave tags and access emements? --jason On Fri, 20 Sep 2002, David Jencks wrote: I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirl ist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional
RE: [JBoss-dev] Build System... any ideas
Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any
RE: [JBoss-dev] Build System... any ideas
I can't release the scripts from the company I work at, but I can point you to a project I work on that is simply a website put together using XSL + XML. It uses the same principles in its design and should give you an overview. Using anon CVS to fetch: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin co ccaustin Again, no J2EE but the concepts are there. Basically, it uses a sitemap in XML as its data source. So, I use XSL to generate a script to generate HTML using XSL ;) Just apply this concept to generating Ant scripts of any sort, including module building and deployment, classpaths for modules based on jar dependencies, etc. James -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 3:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlis t Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would
RE: [JBoss-dev] Continuous Integration
I have just recently started down the cruise control path on a personal project, and my company has since dumped it in favor of an Austin-based startup (Buildforge) which offers better support and feature set. Basically, I have found that if you don't use the exact version of Ant and scripts that they use, you won't get the behavior as expected. Thus, you end up doing a lot of your own coding and config work to make cruise control happy. Some is acceptable, but we practically rewrote the thing and some of our ant scripts to get it all to play nice. On my plate still is a task to try to use their modification-set tag and from a 10 min cron job, run a target that uses that tag to determine if a build is needed. If not, it will just return quietly. Hokey, but I haven't found anything better out there unless I just use their code to create something better. I'll look into that other link that was sent out - lubega.com was it? James -Original Message- From: Kevin Conner [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 10:09 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Continuous Integration Right, a build initiated on checkin is in general guarenteed to fail due to an inconsistent view of the repository. Start bitching more about specific problems due to checkins that developers are not fixing. If it continues unabated the offending developer is gone. It's not initiated on checkin though, it polls the CVS repository for changes and will initiate the build once the changes have settled down. This is all configurable in cruisecontrol. If the build fails then cruisecontrol will email the people who checked in code since the previous checkout. The idea is that this should be frequent enough to catch small amounts of changes which cause problems. I've introduced cruisecontrol here so that we can automate builds and testing. It has been good for us as we are a small team. Having said all that, I'm not sure that there is any benefit of using this in jboss if there is already a mechanism to build on a regular interval (which there is). If you were starting from scratch then I would certainly recommend cruisecontrol but why change if your current mechanism is sufficient? Kev Kevin Conner Orchard Information Systems Limited Newcastle Technopole, Kings Manor Newcastle Upon Tyne, NE1 6PA. United Kingdom Registered in England, Number 1900078 Tel: +44 (0) 191-2032536 Fax: +44 (0) 191 2302515 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Continuous Integration
The new 2.0 version that will be out soon is significantly better. Even so, I never had much trouble with the old version. Glad to hear you had better success, and I'm eager for a new version to give it another shot. Besides CruiseControl is Open Source. If there are problems, get the source and fix them. Uh, we did that. That's why I said you end up doing a lot of your own coding and config work to make cruise control happy. Thus, we did extend it. In fact, we have a version that is so far from the original with our own customizations, we may release it to the public if anyone thinks its worthwhile to their project. Lots of configuration additions mostly. Are you going to tell me I should buy Weblogic too? Um, no, but feel free to if you feel so inclined. I prefer Jboss. Best Regards, James --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Castor XML users; can you drop some knowledge
It just so happens that I was doing some of this work yesterday. I will send an email to you directly with a zip archive (as not to spam the general jboss group) of a generated XSD from your sample, and simple .bat to kick off Castor's src generator, and the resulting classes. James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 5:56 PM To: 'Jboss-Development@Lists. Sourceforge. Net' Subject: [JBoss-dev] Castor XML users; can you drop some knowledge Hiya, I am looking for someone who is familiar with Castor XML to bind XML to Java (and via versa). Basically what I would like is for you to take an example XML document, create the XML schema and either provide the impl classes or provide a runnable example to make use of the class generator. I think this is fairly easy todo, that is if you are familiar with XML schemas and the Castor XML bits. I have looked over both, but have not had time to get something working just yet. There are entirely too many things todo. So it might seem like I am lazy, but really I am just trying to do more with less time. I am hoping to take this example and learn how the system works by it, instead of spending countless hours in trail and error. Are you down? I hope so. Let me know (don't worry I don't bite). Attached is the example XML doc, which is for the JBoss/Console configuration. Thanks, --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Resend: EJB statistics?
Title: Message Is there a way to determine what the current size of the cache,requests, other performance indicatorsfor an EJB via the JMX 8082 viewer? Or, is there anything else out there that acts similiar to the weblogic console for seeing what thestats are for an EJBto better tune deployment settings? Thanks, James
RE: [JBoss-dev] Where should the Jasper jar live ?
David, You can add any extension to the archive mode with the following code in your .emacs: (setq auto-mode-alist (cons '(\\.sar$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.war$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.ear$ . archive-mode) auto-mode-alist)) Share and Enjoy, James -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:07 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I still like the sar concept. I notice that emacs can edit files in jars (such as ejb-jar.xml) and save them back into the jar. Anyone know enough elisp to figure out how to make it edit .sar, .ear, .war, etc the same way? (I presume it just means recognizing the file format/extension as zip-like) Then there won't be anything to complain about having to repack for small changes. For large changes you'll be doing an ant build anyway. david jencks On 2002.05.31 21:04:26 -0400 Jules Gosnell wrote: The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Likewise, the sar is a nice extension of the J2EE packaging metaphor. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Jules Scott M Stark wrote: That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las
RE: [JBoss-dev] XDoclet and C# style metadata
Not sure if this helps, but JDK 1.5 is planning to put this in and make the meta data accessible from the runtime as well as tools like Javadoc. James -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 4:08 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XDoclet and C# style metadata Unless the getClassMetaData() loaded up the config info from a resource xml file. The XDoclet stuff would just generate the getClassMetaData() method (that just loads the data from the xml file) and the .xml that holds the class metadata. If getClassMetaData() returned a really generic object like a xml dom, then you would never have to change getClassMetaData(). Regards, Hiram From: Dain Sundstrom [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XDoclet and C# style metadata Date: Fri, 17 May 2002 14:12:53 -0500 Ok, I'm responding to my own email. Sometimes I get to excited. This is technique will only be useful in some circumstances because it requires changing your source code to change a simple configuration. In my case this is acceptable, because I'm talking about test cases. It would also be useful for many EJB programmers, as they use XDoclet to set TX attributes (although they can still change the dd, they are not editing the source of truth). I still think it would be very useful, but it is not as ungodly powerful as I first thought. -dain Dain Sundstrom wrote: I was just thinking how cool it would be to generically associate xml with a method declaration. Back story: I am working on unit test cases for JBossCMP using JUnitEJB and it would be really useful to mark a test method with a tx attribute. Now this test code is not an EJB or an XMBean, so I don't have a descriptor file (this is not important; I just wanted to avoid the lame make it an ejb emails). Idea (I only know a little about XDoclet an less about C#) Mark up the code with XDoclet tags that contain generic xml. Then run XDoclet to preprocess the java file and generate a new java file with an additional method getClassMetaData. This class would work like the getClass stuff, but would add additional methods to return the extra metadata specified in the class. Use: In my case, the server side tester would get the metadata, check for a tx tag and would start a tx if required by the tag. We could use the same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything. This is something (I think) C# has and is unbelievably powerful. What do you think? -dain ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [JBoss-user] Porting from Weblogic to Jboss
Agreed. On An experimental project, I've used Xdoclet to generate all of my local CMPs, CMRs, and session beans for weblogic. I hope to try and move this to Jboss with a few simple @jboss tags. Depoying a couple of beans to Jboss manually helps understand how it all goes together, as you try to put together WL- Jboss, Xdoclet, and mess with configuration porting. Have fun! James -Original Message- From: Laine Donlan [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 7:30 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Porting from Weblogic to Jboss We too have just finished this task. We used xdoclet to handle much of the configuration issues through the generation of the deployment desciptors, etc. Might be worth looking into. Laine - Original Message - From: James Higginbotham [EMAIL PROTECTED] To: Mahesh Agarwal [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, May 09, 2002 6:18 PM Subject: RE: [JBoss-user] Porting from Weblogic to Jboss Having just taken on this task, I can say with certainty that you may have no problems or plenty :). Most of our issues revolved around understanding custom configuration differences for EJBs between the servers. Jboss.xml, cmp configuration, and JMS configuration isn't hard under Jboss, but it may take a while to move your configurations over to Jboss from weblogic since any custom weblogic configuration must be mapped to a custom jboss configuration by hand. Otherwise, simple stateless beans and a war file are pretty much one-to-one. HTH, James -Original Message- From: Mahesh Agarwal [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 4:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-user] Porting from Weblogic to Jboss hi everyone Do anybody have any document mentioning all the steps to migrate one application from weblogic to Jboss, please send me, it would be helpful for me. Thanks a lot in advance Mahesh ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/j boss-user ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/j boss-user ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/j boss-user ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [JBoss-user] Porting from Weblogic to Jboss
Having just taken on this task, I can say with certainty that you may have no problems or plenty :). Most of our issues revolved around understanding custom configuration differences for EJBs between the servers. Jboss.xml, cmp configuration, and JMS configuration isn't hard under Jboss, but it may take a while to move your configurations over to Jboss from weblogic since any custom weblogic configuration must be mapped to a custom jboss configuration by hand. Otherwise, simple stateless beans and a war file are pretty much one-to-one. HTH, James -Original Message- From: Mahesh Agarwal [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 4:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-user] Porting from Weblogic to Jboss hi everyone Do anybody have any document mentioning all the steps to migrate one application from weblogic to Jboss, please send me, it would be helpful for me. Thanks a lot in advance Mahesh ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/j boss-user ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
