Re: [JBoss-dev] JNuke dev
I tried to do something like this about a year ago but it didn't work with the then-current xdoclet. I think it will be pretty easy with current xdoclet. Marc wanted to do this with ejbs, just drop bean class in, xdoclet generates interfaces, dd, etc, and we deploy. JRun did/does something like this. david jencks On Tuesday, January 14, 2003, at 02:16 PM, Dain Sundstrom wrote: 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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's
RE: Re[2]: [JBoss-dev] JNuke dev
I meant specifying them in XDoclet style, not XML. /** * @classAttr */ class MyClass { /** * @fieldAttr */ private int myField; /** * @methodAttr */ public void myMethod() { BTW, could you please exmplain what is the purpose of the 'name' attribute in class-metadata element? In the forum or here. Thanks, alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Wednesday, January 15, 2003 4:23 PM To: [EMAIL PROTECTED] Subject: RE: Re[2]: [JBoss-dev] JNuke dev Yes definately Alex. I've incorporated the idea of class/method/field metadata in the AOP framework I've been working on. Please refer to the AOP forum. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Loubyansky Sent: Wednesday, January 15, 2003 1:01 AM To: Dain Sundstrom Subject: Re[2]: [JBoss-dev] JNuke dev I also thought about support class/method/field level metadata attributes for aspects deploying the source file this way. But this could be a limiting solution for aspects development. alex Tuesday, January 14, 2003, 9:16:20 PM, you wrote: DS Bill, DS This reminds me of an I deal I has last night (couldn't sleep). I was DS thinking of the script based MBean support Sacha added, and I thought DS can we make plain old java work like a scripting language. Here is DS what I came up with: DS+ The user writes a class BlahService.java DS+ This source file is places in our deployment directory DS+ We run Xdoclet on it to generate the MBean deployment descriptor DS+ We compile the java file DS+ Deploy DS Java as a scripting language. DS What do you think? DS -dain --- 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?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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: Re[2]: [JBoss-dev] JNuke dev
This may or may not disappear. The thought is to name the whole metadata block for purposes of redeployment or undeployment. Am I making sense? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Loubyansky Sent: Wednesday, January 15, 2003 10:56 AM To: [EMAIL PROTECTED] Subject: RE: Re[2]: [JBoss-dev] JNuke dev I meant specifying them in XDoclet style, not XML. /** * @classAttr */ class MyClass { /** * @fieldAttr */ private int myField; /** * @methodAttr */ public void myMethod() { BTW, could you please exmplain what is the purpose of the 'name' attribute in class-metadata element? In the forum or here. Thanks, alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Wednesday, January 15, 2003 4:23 PM To: [EMAIL PROTECTED] Subject: RE: Re[2]: [JBoss-dev] JNuke dev Yes definately Alex. I've incorporated the idea of class/method/field metadata in the AOP framework I've been working on. Please refer to the AOP forum. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Loubyansky Sent: Wednesday, January 15, 2003 1:01 AM To: Dain Sundstrom Subject: Re[2]: [JBoss-dev] JNuke dev I also thought about support class/method/field level metadata attributes for aspects deploying the source file this way. But this could be a limiting solution for aspects development. alex Tuesday, January 14, 2003, 9:16:20 PM, you wrote: DS Bill, DS This reminds me of an I deal I has last night (couldn't sleep). I was DS thinking of the script based MBean support Sacha added, and I thought DS can we make plain old java work like a scripting language. Here is DS what I came up with: DS+ The user writes a class BlahService.java DS+ This source file is places in our deployment directory DS+ We run Xdoclet on it to generate the MBean deployment descriptor DS+ We compile the java file DS+ Deploy DS Java as a scripting language. DS What do you think? DS -dain --- 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?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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
Re[4]: [JBoss-dev] JNuke dev
BB This may or may not disappear. The thought is to name the whole metadata BB block for purposes of redeployment or undeployment. Am I making sense? Frankly, I don't see, currently. I am not asking to remove it, just to clarify. Thanks, alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Loubyansky Sent: Wednesday, January 15, 2003 10:56 AM To: [EMAIL PROTECTED] Subject: RE: Re[2]: [JBoss-dev] JNuke dev I meant specifying them in XDoclet style, not XML. /** * @classAttr */ class MyClass { /** * @fieldAttr */ private int myField; /** * @methodAttr */ public void myMethod() { BTW, could you please exmplain what is the purpose of the 'name' attribute in class-metadata element? In the forum or here. Thanks, alex --- 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
[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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default theme. To make the thing simpler, it will be possible to make theme with JSP because I want to keep post nuke spirit. Ideally, even Module and Blocks could be made as JSP of things like that, that keeps PHP easy to do spirit. I did not thought a lot about permissions. In PostNuke, each module is responsible for checking security. I know that could be done with AOP but I don't know if it's gonna now, later or never :-) One problem is the configuration persistence. I don't know how our JMX implementation is far there. But if there is a restart, all config must be re-done. JMX persistence will save us there. Even though it's plain file and not JDBC. I will check out later (now it's a true mess), but I can say what works : Themes + default theme is done block modules and module invocation. That means that yes, it displays me something that's nice to watch and I can invoke some operations although it's very early. So now, I am going back to code because time matters. julien ___ 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: 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[2]: [JBoss-dev] JNuke dev
I do simply with a ThreadLocal : Page.getPage() and you can output HTML even though have ServletRequest and Response. I do like that because the request thread goes through modules, blocks, and themes and it's a mess that each one pass some parameter when calling another one. julien JH Julien, JH snip JH 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(). JH So, how would you pass arguments from the request to the method in the JH module mbean? Do you plan to just have each method take a hashmap that JH you have constructed from the request? Knowing that modules may need JH arguments for performing work, like a URL to an RSS feed or something. JH Thanks, JH James JH --- JH This SF.NET email is sponsored by: FREE SSL Guide from Thawte JH are you planning your Web Server Security? Click here to get a FREE JH Thawte SSL guide and find the answers to all your SSL security issues. JH http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en JH ___ JH Jboss-development mailing list JH [EMAIL PROTECTED] JH https://lists.sourceforge.net/lists/listinfo/jboss-development -- Best regards, julienmailto:[EMAIL PROTECTED] ___ 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: 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
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
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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default theme. To make the thing simpler, it will be possible to make theme with JSP because I want to keep post nuke spirit. Ideally, even Module and Blocks could be made as JSP of things like that, that keeps PHP easy to do spirit. I did not thought a lot about permissions. In PostNuke, each module is responsible for checking security. I know that could be done with AOP but I don't know if it's gonna now, later or never :-) One problem is the configuration persistence. I don't know how our JMX implementation is far there. But if there is a restart, all config must be re-done. JMX persistence will save us there. Even though it's plain file and not JDBC. I will check out later (now it's a true mess), but I can say what works : Themes + default theme is done block modules and module invocation. That means that yes, it displays me something that's nice to watch
RE: [JBoss-dev] JNuke dev
Also, you can't call it JNuke. You must call it Nukes on Java or something like that. JNuke is trademarked. -Original Message- From: [EMAIL PROTECTED] [mailto:[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 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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default theme. To make the thing simpler, it will be possible to make theme with JSP because I want to keep post nuke spirit. Ideally, even Module and Blocks could be made as JSP of things like that, that keeps PHP easy to do spirit. I did not thought a lot about permissions. In PostNuke, each module is responsible for checking security. I know that could be done with AOP but I don't know if it's gonna now, later or never :-) One problem
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 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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation
Re[2]: [JBoss-dev] JNuke dev
Bill, first of all PostNuke HTML is closer to servlet than JSP. You don't see often HTML with PHP inside, that's the converse thing. You see functions with echo inside. then yes, I want to do that, at least with JSP : %@page % %! public void register() { } other module functions ... % Then JSP can be compiled and become a module. Same with Themes and Blocks. I want to do that, don't worry. I try to keep as close to PostNuke spirit as possible. julien BB The only negative comment I have in using JMX is that the PHP community may BB have a tough time switching over to Nukes on JBoss if you have to have a BB package structure like a SAR or a WAR. I hate to say it, but does it need BB to be dumbed-down for the PHP community? This type of community needs to BB be able to edit a JSP and immediately see the change on the webserver. Is BB it possible to be all JSP based for themes, modules and blocks? You could BB use a URL fragement and JSP:Include to decide what theme to use. BB Just a thought. Maybe JMX and such is the way to go. Just want to give you BB something to think about. BB 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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default theme. To make the thing simpler, it will be possible to make theme with JSP because I want to keep post nuke spirit. Ideally, even Module and Blocks could be made as JSP of things like that, that keeps PHP easy to do spirit. I did not thought a lot about permissions. In PostNuke, each module is responsible for checking security. I know that could be done with AOP but I don't know
Re[2]: [JBoss-dev] JNuke dev
I want best of both worlds that's one of my main concerns, a user that like doing java will do and a user that want thing as simple as editing a JSP will do. I don't say JMX is the way to go, but if I don't choose that, I will have to mimic parts of it. so ? They have kind of registries for modules, themes and blocks in postnuke : with directories. They have a component model, just function call. JMX provide it and it's possible to have still PHP style directories with JSP or similar things inside. julien BS Are we developing this for the PHP community or the Java community? Or BS more important for the JBoss community? To me it seems that it would BS depend on who you are targeting for your user base. If you want to BS target the PHP users to bring them to JBoss, then Bill could be right. BS If we do not care about the PHP community, we go down the JMX way. I BS think the PHP community will never want to do anything with JSP. They BS believe they have what they need to be successful and will continue to BS innovate in their own circle. For most of the PHP community, what they BS 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 BS community may have a tough time switching over to Nukes on JBoss if you have to have BS a package structure like a SAR or a WAR. I hate to say it, but does it BS need to be dumbed-down for the PHP community? This type of community BS needs to be able to edit a JSP and immediately see the change on the webserver. BS Is it possible to be all JSP based for themes, modules and blocks? You BS 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 BS 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 BS 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 BS 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 BS 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 BS fucntionnalities, it's used to manager the PublicModule. Main operations are BS lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and BS 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, BS 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. BS 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), display them on the page. Each block is made
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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default theme. To make the thing simpler, it will be possible to make theme with JSP because I want to keep post nuke spirit. Ideally, even Module and Blocks could be made as JSP of things like that, that keeps PHP easy to do spirit. I did not thought a lot about permissions. In PostNuke, each module is responsible for checking security. I know that could be done with AOP but I don't
Re: [JBoss-dev] JNuke dev
I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: 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 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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc
RE: [JBoss-dev] JNuke dev
I am all for JMX if it works . Also the idea is to port the modules we like bit by bit to the sar format and this is CLEARLY a microkernel job. I think julien stroke on something interesting when he noticed the URL:command mapping to interfaces. What this means is that modules will expose interfaces as mbeans and that is all it takes. Difficult? yeah for php guys, heck they must get EJB first. But for us? we are doing the port anyway... let's go julien, speed speed my friend, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: 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 modules won't be MVC as they simply don't need. It's up
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 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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit
Re[2]: [JBoss-dev] JNuke dev
so far I am not using jboss specific feature : j2ee and jmx. nuke use its own mbean server. I'll try to keep that. NP I would think that we'd want to make this a J2EE application so it can NP run on ANY J2EE application server. Therefore, I would elect to go down NP a pure J2EE route instead of a JBoss only JMX route. NP -Original Message- NP From: [EMAIL PROTECTED] NP [mailto:[EMAIL PROTECTED]] On Behalf Of Ben NP Sabrin NP Sent: Tuesday, January 14, 2003 1:04 PM NP To: [EMAIL PROTECTED] NP Subject: RE: [JBoss-dev] JNuke dev NP Are we developing this for the PHP community or the Java community? Or NP more important for the JBoss community? To me it seems that it would NP depend on who you are targeting for your user base. If you want to NP target the PHP users to bring them to JBoss, then Bill could be right. NP If we do not care about the PHP community, we go down the JMX way. I NP think the PHP community will never want to do anything with JSP. They NP believe they have what they need to be successful and will continue to NP innovate in their own circle. For most of the PHP community, what they NP 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 NP community may have a tough time switching over to Nukes on JBoss if you have to have NP a package structure like a SAR or a WAR. I hate to say it, but does it NP need to be dumbed-down for the PHP community? This type of community NP needs to be able to edit a JSP and immediately see the change on the webserver. NP Is it possible to be all JSP based for themes, modules and blocks? You NP 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 NP 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 NP 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 NP 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 NP 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 NP fucntionnalities, it's used to manager the PublicModule. Main operations are NP lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and NP 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, NP 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. NP 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), display them
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] JNuke dev
I would think that we'd want to make this a J2EE application so it can run on ANY J2EE application server. no we wouldn't. Therefore, I would elect to go down a pure J2EE route instead of a JBoss only JMX route. JMX will be J2EE. Nathan wake up. marcf --- 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?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JNuke dev
You need to think in a one dimensional world. J2EE = JBOSS ! That is the future, learn it, live it, love it A quote from Fast Times at Ridgemont High. Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Nathan Phelps Sent: Tuesday, January 14, 2003 2: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 modules won't be MVC as they simply don't need. It's up to the model to have
RE: [JBoss-dev] JNuke dev
Oh I remember, which is why I feel that we need to concentrate this app towards the Java people not the interesting Perl Mongers:) Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: 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 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
RE: [JBoss-dev] JNuke dev
Again, The type of developer writing content is usually a different calaber than those writing server software. IMHO, it needs to be dumbed-down. The reason why these things like postnuke become so popular is that they are so easy to hack for even the least experienced coder. Copy, cut, paste. Not, write xml, compile, jar, maintain ANT files, etc... You get what I'm saying? This is just something to think about and I'm not advocating any specific approach. And again, BTW, JNuke is already trademarked. You must call in Nukes on JBoss or think of a better name. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Tuesday, January 14, 2003 2:40 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev I am all for JMX if it works . Also the idea is to port the modules we like bit by bit to the sar format and this is CLEARLY a microkernel job. I think julien stroke on something interesting when he noticed the URL:command mapping to interfaces. What this means is that modules will expose interfaces as mbeans and that is all it takes. Difficult? yeah for php guys, heck they must get EJB first. But for us? we are doing the port anyway... let's go julien, speed speed my friend, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: 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
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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs
RE: [JBoss-dev] JNuke dev
What I should have said is content developers. Sorry for the snub, but they do requiring a dumbing down of software. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: 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 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
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
AutoDeploy Source Development ( Was:Re: [JBoss-dev] JNuke dev)
tisdagen den 14 januari 2003 kl 20.16 skrev Dain Sundstrom: 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? I think it is smoking and remember talking around with David and others using ant for the same functionality ... it is a killer develop feature ... This would be great for the kick-start-demos mentioned at around the same time ... The Deploy folder today has CoreContainerComponents and ApplicationDeployments confusing ordering. Maybe separated as sub folders together with a kick-start folder ? ... to help the Deployer in choosing roles ? ... --- 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?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNuke dev
Who is doing the XDoclet integration? I think it would be a good project for that person. -dain On Tuesday, January 14, 2003, at 02:27 PM, Bill Burke wrote: What I should have said is content developers. Sorry for the snub, but they do requiring a dumbing down of software. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: 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 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), display them on the page. Each
RE: [JBoss-dev] JNuke dev
bill, you are about as blue blood system as it gets, you are the one doing AOP inline and staring at the SUN... stop recommending stuff for content developers. Again module developers, even in PHP, are of a different caliber and it is not that bad. They can deal with an MBean... let it be, trust them :) HECK they CREATED POSTNUKE, we got JACK! Also I find the nukes on JBoss name appealing. The name nukes has a light and futuristic feel. Like it goes woosh and frfrrrfr at the same time. marcf --- 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?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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: Re[2]: [JBoss-dev] JNuke dev
JBossNuke ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 12:35 PM To: Bill Burke Subject: Re[2]: [JBoss-dev] JNuke dev ok, do you have a name shorter though ? just nuke for instance ? BB Again, BB The type of developer writing content is usually a different calaber than BB those writing server software. IMHO, it needs to be dumbed-down. The BB reason why these things like postnuke become so popular is that they are so BB easy to hack for even the least experienced coder. Copy, cut, paste. Not, BB write xml, compile, jar, maintain ANT files, etc... You get what I'm BB saying? BB This is just something to think about and I'm not advocating any specific BB approach. BB And again, BTW, JNuke is already trademarked. You must call in Nukes on BB JBoss or think of a better name. BB Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Tuesday, January 14, 2003 2:40 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev I am all for JMX if it works . Also the idea is to port the modules we like bit by bit to the sar format and this is CLEARLY a microkernel job. I think julien stroke on something interesting when he noticed the URL:command mapping to interfaces. What this means is that modules will expose interfaces as mbeans and that is all it takes. Difficult? yeah for php guys, heck they must get EJB first. But for us? we are doing the port anyway... let's go julien, speed speed my friend, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: 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
Re[4]: [JBoss-dev] JNuke dev
what about Nukes on JBoss shortname nukes4j ? JB JBossNuke ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 12:35 PM To: Bill Burke Subject: Re[2]: [JBoss-dev] JNuke dev ok, do you have a name shorter though ? just nuke for instance ? BB Again, BB The type of developer writing content is usually a different calaber than BB those writing server software. IMHO, it needs to be dumbed-down. The BB reason why these things like postnuke become so popular is that they are so BB easy to hack for even the least experienced coder. Copy, cut, paste. Not, BB write xml, compile, jar, maintain ANT files, etc... You get what I'm BB saying? BB This is just something to think about and I'm not advocating any specific BB approach. BB And again, BTW, JNuke is already trademarked. You must call in Nukes on BB JBoss or think of a better name. BB Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Tuesday, January 14, 2003 2:40 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev I am all for JMX if it works . Also the idea is to port the modules we like bit by bit to the sar format and this is CLEARLY a microkernel job. I think julien stroke on something interesting when he noticed the URL:command mapping to interfaces. What this means is that modules will expose interfaces as mbeans and that is all it takes. Difficult? yeah for php guys, heck they must get EJB first. But for us? we are doing the port anyway... let's go julien, speed speed my friend, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: 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
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
Re[2]: [JBoss-dev] JNuke dev
I also thought about support class/method/field level metadata attributes for aspects deploying the source file this way. But this could be a limiting solution for aspects development. alex Tuesday, January 14, 2003, 9:16:20 PM, you wrote: DS Bill, DS This reminds me of an I deal I has last night (couldn't sleep). I was DS thinking of the script based MBean support Sacha added, and I thought DS can we make plain old java work like a scripting language. Here is DS what I came up with: DS+ The user writes a class BlahService.java DS+ This source file is places in our deployment directory DS+ We run Xdoclet on it to generate the MBean deployment descriptor DS+ We compile the java file DS+ Deploy DS Java as a scripting language. DS What do you think? DS -dain DS 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), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default