Re[2]: JBossScript was RE: [JBoss-dev] JNuke dev
Hi, Tuesday, January 14, 2003, 6:19:23 PM, you wrote: ws And what would be the goal for that? ws Could you give examples? I have another idea scripts use inside JBoss. The discussion here is to deploy scripts and then a deployer will converted they to MBean/Session beans and so on. My idea is to have a script engine inside JBoss to be used by clients. This is what I want to do : - a simple MBean with a method show() - inside this method the BeanShell console is called - this will popup a console on the screen where the user can type and execute scripts. This can be used to test beans and so on. It runs inside JBoss. I have a very simple prototype of this, and I will make it avaliable tomorrow. What is the apropriate forum to discuss this ? Comments ? -- Best regards, Danilomailto:[EMAIL PROTECTED] --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[3]: JBossScript was RE: [JBoss-dev] JNuke dev
Wednesday, January 15, 2003, 3:27:16 PM, you wrote: DLR This can be used to test beans and so on. It runs inside JBoss. DLR I have a very simple prototype of this, and I will make it avaliable DLR tomorrow. Install this SAR to a simple example : http://www.danilo.floripa.com.br/script-mbean.sar Invoke the show() method of the Sigea:service=SigeaScriptManager MBean. You must to be on the same machine of the server. You will see the BeanShell Desktop. It is running in the same VM of JBoss. So it can be used to write scripts in a very convenient way. There are some problems with this quick sample : - It uses the BeanShell Desktop class, and it was done to be a standalone application. So when you exit it will shutdown your jboss server. In a production implementation we need to fix this. - There are no access to all the classes on the JBoss enviroment. Click with the right button on the BeanShell Desktop and click on new class browser to see what is avaliable to scripts. I need to study more the classloader architecture to make this really work. What do you think ? This can be usefull ? -- Best regards, Danilomailto:[EMAIL PROTECTED] --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
JBossScript was RE: [JBoss-dev] JNuke dev
Anybody want to take this on? Could be an interesting project. I think the idea has merit Dain. Great thought. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev Its a good idea. Anybody want to implement this? JBossScript we can call it. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev Bill, This reminds me of an I deal I has last night (couldn't sleep). I was thinking of the script based MBean support Sacha added, and I thought can we make plain old java work like a scripting language. Here is what I came up with: + The user writes a class BlahService.java + This source file is places in our deployment directory + We run Xdoclet on it to generate the MBean deployment descriptor + We compile the java file + Deploy Java as a scripting language. What do you think? -dain On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: 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 modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks),
RE: JBossScript was RE: [JBoss-dev] JNuke dev
dain :) marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:32 PM To: [EMAIL PROTECTED] Subject: JBossScript was RE: [JBoss-dev] JNuke dev Anybody want to take this on? Could be an interesting project. I think the idea has merit Dain. Great thought. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev Its a good idea. Anybody want to implement this? JBossScript we can call it. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev Bill, This reminds me of an I deal I has last night (couldn't sleep). I was thinking of the script based MBean support Sacha added, and I thought can we make plain old java work like a scripting language. Here is what I came up with: + The user writes a class BlahService.java + This source file is places in our deployment directory + We run Xdoclet on it to generate the MBean deployment descriptor + We compile the java file + Deploy Java as a scripting language. What do you think? -dain On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: 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 modules won't be MVC as they simply don't need. It's up
RE: JBossScript was RE: [JBoss-dev] JNuke dev
Hello, And what would be the goal for that? Could you give examples? regards, WS --- marc fleury [EMAIL PROTECTED] a écrit : dain :) marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:32 PM To: [EMAIL PROTECTED] Subject: JBossScript was RE: [JBoss-dev] JNuke dev Anybody want to take this on? Could be an interesting project. I think the idea has merit Dain. Great thought. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev Its a good idea. Anybody want to implement this? JBossScript we can call it. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev Bill, This reminds me of an I deal I has last night (couldn't sleep). I was thinking of the script based MBean support Sacha added, and I thought can we make plain old java work like a scripting language. Here is what I came up with: + The user writes a class BlahService.java + This source file is places in our deployment directory + We run Xdoclet on it to generate the MBean deployment descriptor + We compile the java file + Deploy Java as a scripting language. What do you think? -dain On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: 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 : === message truncated === ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl
RE: JBossScript was RE: [JBoss-dev] JNuke dev
Do you use XDoclet to generate your EJB files? Think of writing your Bean.java file, plopping it in the jboss deploy directory, and magically, the bean is ready for use. Edit the Bean.java file in the deploy directory and the bean magically gets redeployed with your changes. Think of JSPs. That is a good analogy. JSPs get compiled into Java servlet code, then compiled into a class. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of wonder sonic Sent: Tuesday, January 14, 2003 4:19 PM To: [EMAIL PROTECTED] Subject: RE: JBossScript was RE: [JBoss-dev] JNuke dev Hello, And what would be the goal for that? Could you give examples? regards, WS --- marc fleury [EMAIL PROTECTED] a écrit : dain :) marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:32 PM To: [EMAIL PROTECTED] Subject: JBossScript was RE: [JBoss-dev] JNuke dev Anybody want to take this on? Could be an interesting project. I think the idea has merit Dain. Great thought. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev Its a good idea. Anybody want to implement this? JBossScript we can call it. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev Bill, This reminds me of an I deal I has last night (couldn't sleep). I was thinking of the script based MBean support Sacha added, and I thought can we make plain old java work like a scripting language. Here is what I came up with: + The user writes a class BlahService.java + This source file is places in our deployment directory + We run Xdoclet on it to generate the MBean deployment descriptor + We compile the java file + Deploy Java as a scripting language. What do you think? -dain On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: 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
Re[2]: JBossScript was RE: [JBoss-dev] JNuke dev
that would be nice if deployer could create bean metadata directly without creating descriptors and then directly deploy the bean with metadata. reuse xdoclet code and generate metadata instead of writing DD that would be reparsed anyway to generate same data later. BB Do you use XDoclet to generate your EJB files? BB Think of writing your Bean.java file, plopping it in the jboss deploy BB directory, and magically, the bean is ready for use. BB Edit the Bean.java file in the deploy directory and the bean magically gets BB redeployed with your changes. BB Think of JSPs. That is a good analogy. JSPs get compiled into Java servlet BB code, then compiled into a class. BB Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of wonder sonic Sent: Tuesday, January 14, 2003 4:19 PM To: [EMAIL PROTECTED] Subject: RE: JBossScript was RE: [JBoss-dev] JNuke dev Hello, And what would be the goal for that? Could you give examples? regards, WS --- marc fleury [EMAIL PROTECTED] a écrit : dain :) marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:32 PM To: [EMAIL PROTECTED] Subject: JBossScript was RE: [JBoss-dev] JNuke dev Anybody want to take this on? Could be an interesting project. I think the idea has merit Dain. Great thought. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 3:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev Its a good idea. Anybody want to implement this? JBossScript we can call it. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev Bill, This reminds me of an I deal I has last night (couldn't sleep). I was thinking of the script based MBean support Sacha added, and I thought can we make plain old java work like a scripting language. Here is what I came up with: + The user writes a class BlahService.java + This source file is places in our deployment directory + We run Xdoclet on it to generate the MBean deployment descriptor + We compile the java file + Deploy Java as a scripting language. What do you think? -dain On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: 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
