|
»
« Return to Thread: RIFE/Modules (was: Here's a handy little utility element)
Re: RIFE/Modules
by Geert Bevin
::
Rate this Message:
> (Isn't rife-crud-*.jar included in the Jumpstart distribution?)
Yeah, it is. Of course its jars are not include into RIFE/Crud
itself. The structure is though, with the project files, Jetty, ...
> You're right, I misunderstood. I took "the advantage of including
> the jumpstart..." to mean that you were thinking of packaging each
> module with a complete copy of the jumpstart.
>
>> This is not possible since RIFE looks up everything through the
>> claspath. File globbing is thus not an option.
>
> I think a good goal, though maybe others disagree, is to let
> someone just plop a module jarfile in their lib directory, restart
> Jetty, and go to a demo page to start playing with the module. No
> config file editing needed. That goal requires some kind of
> automatic detection of modules, and of course you might have any
> number of modules in any combination at any given time.
The main question here is what to achieve with that. I see RIFE/
Modules as a collection of reusable elements and sites. To use them,
people will have to include them into their sites and customize them
through properties. They might even want to put authentication on top
of them, link them into existing flows, use them as embedded
elements, ...
What you're describing sounds more like a CMS, which would be cool
too btw. Being able to drop in jars and automatically 'register' them
with the CMS system is indeed very powerful. An administration
interface could then allow people to manage a site-structure
intuitively and plug the 'modules' into the rest of the site and
customize them.
> Is it possible to distinguish between multiple instances of the
> same resource on the classpath? If so, then a simple solution might
> be for each module to include a "rife/modules/module.xml" or
> somesuch, that declares the elements (and/or participants?) defined
> by that particular module as well as a set of demo pages. The
> module element/participant implementations, demo element
> implementations, and demo templates would of course have unique
> names. The module autoloading would be done by a new participant
> which takes a parameter to control whether demo environments get
> set up; for a production environment you'd turn that option off.
> The autoloader could even have a little informational UI of its own
> with a description of each module and a link to the corresponding
> demo page. You could also, of course, explicitly declare the module
> elements/participants in your configuration and not use autoloading
> at all.
This is possible in several ways:
* use a dedicated classloader for each module jar and put all those
jars in a specific location so that their names can be detected
* rely on the jar manifest to provide this information instead of an
XML file, this does require quite some additional code in
EngineClassLoader since RIFE doesn't use the manifest information at
all atm because the JDKs URLClassLoader doesn't provide an API to be
able to access its cached resources and meta data. Due to this we'd
have to develop a parallel resource hierarchy caching mechanism
ourselves, which is a lot of work, duplicated the memory footprint
for that, and will slow down resource retrieval. Without such a
caching system however, finding resources really crawls though.
> If it's not possible to distinguish identically-named resources on
> the classpath, and the zero-configuration-required goal is a good
> one, maybe this calls for a hack. Since we will be packaging the
> modules in a coordinated way, we can give each one a number. Start
> with 1 and work our way up. The jumpstart distribution can know how
> many official modules were available at the time it was built. The
> module-loading participant can scan for rife/modules/1.xml, rife/
> modules/2.xml, etc., up to some reasonable number higher than the
> highest known official module at release time. The scan only needs
> to happen once at startup time, so it should not be a performance
> problem.
I don't like this much since it kind of prevents people from
developing custom modules for themselves without fearing that one day
they'll have a conflicting number. A huge hack indeed! ;-)
> I said it was a hack! :)
>
> It might be reasonable to just tell people to edit their config
> files, of course, but IMO the less effort between downloading a
> module and trying it out locally, the better. Plus it would make
> RIFE the only framework with true drop-in-and-use extension
> support, which would be pretty cool in itself!
>
> -Steve
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel
Yeah, it is. Of course its jars are not include into RIFE/Crud
itself. The structure is though, with the project files, Jetty, ...
> You're right, I misunderstood. I took "the advantage of including
> the jumpstart..." to mean that you were thinking of packaging each
> module with a complete copy of the jumpstart.
>
>> This is not possible since RIFE looks up everything through the
>> claspath. File globbing is thus not an option.
>
> I think a good goal, though maybe others disagree, is to let
> someone just plop a module jarfile in their lib directory, restart
> Jetty, and go to a demo page to start playing with the module. No
> config file editing needed. That goal requires some kind of
> automatic detection of modules, and of course you might have any
> number of modules in any combination at any given time.
The main question here is what to achieve with that. I see RIFE/
Modules as a collection of reusable elements and sites. To use them,
people will have to include them into their sites and customize them
through properties. They might even want to put authentication on top
of them, link them into existing flows, use them as embedded
elements, ...
What you're describing sounds more like a CMS, which would be cool
too btw. Being able to drop in jars and automatically 'register' them
with the CMS system is indeed very powerful. An administration
interface could then allow people to manage a site-structure
intuitively and plug the 'modules' into the rest of the site and
customize them.
> Is it possible to distinguish between multiple instances of the
> same resource on the classpath? If so, then a simple solution might
> be for each module to include a "rife/modules/module.xml" or
> somesuch, that declares the elements (and/or participants?) defined
> by that particular module as well as a set of demo pages. The
> module element/participant implementations, demo element
> implementations, and demo templates would of course have unique
> names. The module autoloading would be done by a new participant
> which takes a parameter to control whether demo environments get
> set up; for a production environment you'd turn that option off.
> The autoloader could even have a little informational UI of its own
> with a description of each module and a link to the corresponding
> demo page. You could also, of course, explicitly declare the module
> elements/participants in your configuration and not use autoloading
> at all.
This is possible in several ways:
* use a dedicated classloader for each module jar and put all those
jars in a specific location so that their names can be detected
* rely on the jar manifest to provide this information instead of an
XML file, this does require quite some additional code in
EngineClassLoader since RIFE doesn't use the manifest information at
all atm because the JDKs URLClassLoader doesn't provide an API to be
able to access its cached resources and meta data. Due to this we'd
have to develop a parallel resource hierarchy caching mechanism
ourselves, which is a lot of work, duplicated the memory footprint
for that, and will slow down resource retrieval. Without such a
caching system however, finding resources really crawls though.
> If it's not possible to distinguish identically-named resources on
> the classpath, and the zero-configuration-required goal is a good
> one, maybe this calls for a hack. Since we will be packaging the
> modules in a coordinated way, we can give each one a number. Start
> with 1 and work our way up. The jumpstart distribution can know how
> many official modules were available at the time it was built. The
> module-loading participant can scan for rife/modules/1.xml, rife/
> modules/2.xml, etc., up to some reasonable number higher than the
> highest known official module at release time. The scan only needs
> to happen once at startup time, so it should not be a performance
> problem.
I don't like this much since it kind of prevents people from
developing custom modules for themselves without fearing that one day
they'll have a conflicting number. A huge hack indeed! ;-)
> I said it was a hack! :)
>
> It might be reasonable to just tell people to edit their config
> files, of course, but IMO the less effort between downloading a
> module and trying it out locally, the better. Plus it would make
> RIFE the only framework with true drop-in-and-use extension
> support, which would be pretty cool in itself!
>
> -Steve
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel
« Return to Thread: RIFE/Modules (was: Here's a handy little utility element)
| Free embeddable forum powered by Nabble | Forum Help |
