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
