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
>
> 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=User&op=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
> >>>
>
>
>
>
> -------------------------------------------------------
> 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: 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

Reply via email to