You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by "Johan Lindquist (JIRA)" <hi...@jakarta.apache.org> on 2005/01/25 16:56:17 UTC
[jira] Created: (HIVEMIND-85) Adds condtional inclusion of sub-modules
Adds condtional inclusion of sub-modules
----------------------------------------
Key: HIVEMIND-85
URL: http://issues.apache.org/jira/browse/HIVEMIND-85
Project: HiveMind
Type: Improvement
Components: framework, documentation
Versions: 1.1
Reporter: Johan Lindquist
Priority: Minor
Attachments: jakarta-hivemind-conditional-submodule.patch, jakarta-hivemind-conditional-submodule.tar.gz
Provided patch (and tar bundle) adds conditionals support for sub-module descriptor elements. Included junit tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Updated: (HIVEMIND-85) Adds condtional inclusion of sub-modules
Posted by "Johan Lindquist (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-85?page=history ]
Johan Lindquist updated HIVEMIND-85:
------------------------------------
Attachment: jakarta-hivemind-conditional-submodule.patch
patch set
> Adds condtional inclusion of sub-modules
> ----------------------------------------
>
> Key: HIVEMIND-85
> URL: http://issues.apache.org/jira/browse/HIVEMIND-85
> Project: HiveMind
> Type: Improvement
> Components: framework, documentation
> Versions: 1.1
> Reporter: Johan Lindquist
> Priority: Minor
> Attachments: jakarta-hivemind-conditional-submodule.patch, jakarta-hivemind-conditional-submodule.tar.gz
>
> Provided patch (and tar bundle) adds conditionals support for sub-module descriptor elements. Included junit tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Updated: (HIVEMIND-85) Adds condtional inclusion of sub-modules
Posted by "Johan Lindquist (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-85?page=history ]
Johan Lindquist updated HIVEMIND-85:
------------------------------------
Attachment: jakarta-hivemind-conditional-submodule.tar.gz
> Adds condtional inclusion of sub-modules
> ----------------------------------------
>
> Key: HIVEMIND-85
> URL: http://issues.apache.org/jira/browse/HIVEMIND-85
> Project: HiveMind
> Type: Improvement
> Components: framework, documentation
> Versions: 1.1
> Reporter: Johan Lindquist
> Priority: Minor
> Attachments: jakarta-hivemind-conditional-submodule.patch, jakarta-hivemind-conditional-submodule.tar.gz
>
> Provided patch (and tar bundle) adds conditionals support for sub-module descriptor elements. Included junit tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: module descriptor caching
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'm not certain that de-serializing is going to be any faster than XML
parsing. Even with Externalizable, Java serialization is slow.
Serialization can save bytes but not necessarily cycles. Not
necessarily bytes either, depending on the circumstance. ERH has
blogged about this in the past.
I suspect the largest slice of time is class loading, which you pay
for either way.
I think we can speed up HiveMind in a few ways (off the top of my
head, no order, some undesirable):
1) Change the OuterProxy/InnerProxy pair down to just a single Proxy.
That's one less class to create for each service. The cost is the
need to synchronize the method that will just-in-time instantiate the
service. We had a discussion about this, and the ephemeral threading
bug behind the scenes, last week.
2) Instantiating services with BuilderFactory involves a large number
of reflective calls. We have discussed the idea of delegating service
construction out to static methods of a per-module class. This should
reduce the cost of instantiating a service down to a single reflective
call.
3) Wait for CPUs to get faster :-)
4) Latch HiveMind to JDK 1.5 and start using read/write locks instead
of synchronization for greater parallelism (won't help startup, may
hurt it).
5) Streamline parsing further, perhaps by eliminating the use of
regexp validation of some attributes.
6) Ditch commons-logging in favor of something homebrew, or JDK 1.4
logging, or that alternative to commons-logging
(http://www.slf4j.org/)
There may be other areas to investigate. Are we using proper buffers
when parsing the XML? You get a pretty big performance boost by
wrapping a FileInputStream inside a BufferedInputStream [actually,
I've tested this with the debugger, and we seem to have a decent stack
of input streams by the time we get into the parser code].
I've circled around this a number of times. I've thought about moving
most of the HiveMind logic into a build phase that would generate
classes at build time (as in, no XML parsing or class creation at
runtime) ... but that makes the build/deploy/test cycle much more
complex and the runtime structure of the application more rigid.
Also, I'd like to keep HiveMind 99.9% backwards compatible (Tapestry
backwards compatibility is already a thorn in my side, and of the
Tapestry users' sides).
I noticed that it's 20% parsing time, 80% inside startup code. Again,
I think we need to see more of what's going on inside the 80% and I
suspect most of it is class loading time. How much of that is
Javassist class creation is another question.
On 6/25/06, Knut Wannheden <kn...@gmail.com> wrote:
> Achim,
>
> > > - I see that you're using the concept of natures on modules,
> > > extenstion points and extenstions, where XML would be an example of
> > > such a nature. That looks like a very interesting idea. As you don't
> > > have a defined interface for these natures it seems to me that they're
> > > more like adapters.
> > >
> > I was inspired by the eclipse natures (for example a tomcat nature)
> > which provide
> > additional information to a project. The adapter pattern usually deals
> > with conversion of
> > incompatible interfaces which is not the case here.
> >
>
> I see. What confused me was that the way I've seen Eclipse project
> natures being used is that they must implement a defined lifecycle
> interface which allows them to hook in certain behaviours when the
> nature is first added and when it's removed. It seems like your
> natures can really be any POJO and can / will be used by any other
> object whenever required. I thought this was more similar to the
> IAdaptable interface used throughout the Eclipse APIs (according to
> the following article this is really an example of the extension
> object pattern:
> http://www.artima.com/lejava/articles/designprinciples.html). Also EMF
> is using something similar they call adapters but aren't truly
> adapters in the GoF pattern style.
>
> > > - The configuration points also seem to declare a constructor which is
> > > responsible for constructing the container object. Is here the idea
> > > that a configuration can have multiple containers (as currently with
> > > Map and List) and thus constructors?
> > >
> > No, I decided to break backward compatibility here. A configuration must
> > have exactly
> > one type. IMO the support for mappable configurations in hivemind 1.x is
> > simply a concession
> > to the need for different configuration types. If you need a
> > configuration as map and list,
> > then define and inject it as map and call map.values(). Migration is
> > quite easy.
> >
>
> OK. I wasn't quite clear on the idea there.
>
> > > - In the org.apache.hivemind.definiton package the concrete
> > > ExtensionDefinition objects are not owned by the *ModuleDefinition*
> > > object but instead directly to the respective ExtensionPointDefinition
> > > object. I get the impression that this couples modules in such a way
> > > that it isn't possible to define them independently. IMO it would be
> > > better to keep the ExtensionDefinition objects under the
> > > *ModuleDefinition* object and have a reference by ID to the
> > > ExtensionPointDefinition.
> > >
> > Both is possible. The direct addition to the extension point is the most
> > comfortable way
> > if you define a complete module. Additionally it is possible to define
> > "unresolved" extensions that
> > reference the points by id. The corresponding methods are defined in
> > RegistryDefinition
> > in the moment and here you are right, they should be moved to
> > ModuleDefinition.
>
> IMHO I think the "comfortable way" could be implemented by a
> implementation of the registry definition API specific for defining
> modules in plain Java code (as in your example).
>
> > > - IMHO defining the *Definition objects as interfaces would have some
> > > advantages.
> > >
> > Ok, but I would introduce interfaces when the api is stable.
> >
>
> Makes perfect sense.
>
> > > Anyway I think this is looking very good. Let me know if there's
> > > anything I can help you with.
> > >
> > A most welcome addition would be a refactoring of the dependency injection.
> > It's coupled with the xml specific BuilderFactory in the moment, which makes
> > it difficult to reuse with pure java or annotated java modules.
> >
>
> Maybe we could reuse code or the concepts from commons proxy for this.
>
> --knut
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: module descriptor caching
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
> > - I see that you're using the concept of natures on modules,
> > extenstion points and extenstions, where XML would be an example of
> > such a nature. That looks like a very interesting idea. As you don't
> > have a defined interface for these natures it seems to me that they're
> > more like adapters.
> >
> I was inspired by the eclipse natures (for example a tomcat nature)
> which provide
> additional information to a project. The adapter pattern usually deals
> with conversion of
> incompatible interfaces which is not the case here.
>
I see. What confused me was that the way I've seen Eclipse project
natures being used is that they must implement a defined lifecycle
interface which allows them to hook in certain behaviours when the
nature is first added and when it's removed. It seems like your
natures can really be any POJO and can / will be used by any other
object whenever required. I thought this was more similar to the
IAdaptable interface used throughout the Eclipse APIs (according to
the following article this is really an example of the extension
object pattern:
http://www.artima.com/lejava/articles/designprinciples.html). Also EMF
is using something similar they call adapters but aren't truly
adapters in the GoF pattern style.
> > - The configuration points also seem to declare a constructor which is
> > responsible for constructing the container object. Is here the idea
> > that a configuration can have multiple containers (as currently with
> > Map and List) and thus constructors?
> >
> No, I decided to break backward compatibility here. A configuration must
> have exactly
> one type. IMO the support for mappable configurations in hivemind 1.x is
> simply a concession
> to the need for different configuration types. If you need a
> configuration as map and list,
> then define and inject it as map and call map.values(). Migration is
> quite easy.
>
OK. I wasn't quite clear on the idea there.
> > - In the org.apache.hivemind.definiton package the concrete
> > ExtensionDefinition objects are not owned by the *ModuleDefinition*
> > object but instead directly to the respective ExtensionPointDefinition
> > object. I get the impression that this couples modules in such a way
> > that it isn't possible to define them independently. IMO it would be
> > better to keep the ExtensionDefinition objects under the
> > *ModuleDefinition* object and have a reference by ID to the
> > ExtensionPointDefinition.
> >
> Both is possible. The direct addition to the extension point is the most
> comfortable way
> if you define a complete module. Additionally it is possible to define
> "unresolved" extensions that
> reference the points by id. The corresponding methods are defined in
> RegistryDefinition
> in the moment and here you are right, they should be moved to
> ModuleDefinition.
IMHO I think the "comfortable way" could be implemented by a
implementation of the registry definition API specific for defining
modules in plain Java code (as in your example).
> > - IMHO defining the *Definition objects as interfaces would have some
> > advantages.
> >
> Ok, but I would introduce interfaces when the api is stable.
>
Makes perfect sense.
> > Anyway I think this is looking very good. Let me know if there's
> > anything I can help you with.
> >
> A most welcome addition would be a refactoring of the dependency injection.
> It's coupled with the xml specific BuilderFactory in the moment, which makes
> it difficult to reuse with pure java or annotated java modules.
>
Maybe we could reuse code or the concepts from commons proxy for this.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: module descriptor caching
Posted by Achim Hügen <ac...@gmx.de>.
Hi Knut,
> Hi Achim,
>
> Caching the module descriptors by serializing them as a Java class
> similar to what you describe is also a solution I've thought about.
> And that is then of course very closely related to what you're working
> on. Given my findings about the relatively low overhead of parsing the
> XML module descriptors when constructing a registry I think I will let
> that idea rest for a while. So I'll rather try to help you out in your
> effort.
>
> I've taken a first look at what you've done in your branch and think
> it's shaping up really well. It's very much like what I had in mind. I
> understand that this is a work in progress but here are a few
> questions and comments I have:
>
> - I see that you're using the concept of natures on modules,
> extenstion points and extenstions, where XML would be an example of
> such a nature. That looks like a very interesting idea. As you don't
> have a defined interface for these natures it seems to me that they're
> more like adapters.
>
I was inspired by the eclipse natures (for example a tomcat nature)
which provide
additional information to a project. The adapter pattern usually deals
with conversion of
incompatible interfaces which is not the case here.
> - The configuration points also seem to declare a constructor which is
> responsible for constructing the container object. Is here the idea
> that a configuration can have multiple containers (as currently with
> Map and List) and thus constructors?
>
No, I decided to break backward compatibility here. A configuration must
have exactly
one type. IMO the support for mappable configurations in hivemind 1.x is
simply a concession
to the need for different configuration types. If you need a
configuration as map and list,
then define and inject it as map and call map.values(). Migration is
quite easy.
> - In the org.apache.hivemind.definiton package the concrete
> ExtensionDefinition objects are not owned by the *ModuleDefinition*
> object but instead directly to the respective ExtensionPointDefinition
> object. I get the impression that this couples modules in such a way
> that it isn't possible to define them independently. IMO it would be
> better to keep the ExtensionDefinition objects under the
> *ModuleDefinition* object and have a reference by ID to the
> ExtensionPointDefinition.
>
Both is possible. The direct addition to the extension point is the most
comfortable way
if you define a complete module. Additionally it is possible to define
"unresolved" extensions that
reference the points by id. The corresponding methods are defined in
RegistryDefinition
in the moment and here you are right, they should be moved to
ModuleDefinition.
> - IMHO defining the *Definition objects as interfaces would have some
> advantages.
>
Ok, but I would introduce interfaces when the api is stable.
> Anyway I think this is looking very good. Let me know if there's
> anything I can help you with.
>
A most welcome addition would be a refactoring of the dependency injection.
It's coupled with the xml specific BuilderFactory in the moment, which makes
it difficult to reuse with pure java or annotated java modules.
Achim
> --knut
>
> On 6/22/06, Achim Hügen <achim.huegen <at> gmx.de> wrote:
> > Knut,
> >
> > it would be great to have an fast and comfortable way of loading
> > serialized or preprocessed registries.
> > Though I personally would like to shift these efforts to hivemind 2
> > or at least to what I think hivemind 2 could be.
> > Like I mentioned here
> > http://article.gmane.org/gmane.comp.jakarta.hivemind.devel/2333
> > some weeks ago, I'm working at a prototype, that features
> > a programmatic way of defining registries. The data structures are
> > based on your ideas in the wiki:
> > http://wiki.apache.org/jakarta-hivemind/DescriptorApiRevampProposal
> > Have a look here for the current status:
> > https://svn.apache.org/repos/asf/jakarta/hivemind/branches/branch-2-0-annot/framework/src/java/org/apache/hivemind/definition/
> >
> > This results in a nice xml independent object graph and a straight forward
> > registry building which might be a good starting point for serialization.
> > Wait ... probably the fastest way to load a registry is the use of the
> > programmatic registry api. One could transform the xml module to a
> > java class that contains a sequence of api calls. Example:
> >
> > <module id="hivemind.tests.serviceByInterface" version="1.0.0">
> > <service-point id="uniqueService"
> > interface="hivemind.test.IUniqueService">
> > <create-instance class="hivemind.test.UniqueServiceImpl"/>
> > </service-point>
> > </module>
> >
> > would be transformed to:
> >
> > class ServiceByInterfaceModule {
> >
> > process(RegistryDefinition registry)
> > {
> > *ModuleDefinition* module = new
> > *ModuleDefinition*("hivemind.tests.serviceByInterface");
> >
> > ServicePointDefinition sp = new
> > ServicePointDefinition("uniqueService", Visibility.PUBLIC,
> > IUniqueService.class);
> > module.addServicePoint(sp);
> >
> > ServiceImplementationDefinition impl = new
> > ServiceImplementationDefinition(
> > new CreateClassServiceConstructor("module",
> > UniqueServiceImpl.class),
> > "singleton", true);
> > sp.addImplementation(impl);
> >
> > registry.addModule(module);
> > }
> > }
> >
> > What do you think?
> >
> > Achim
> >
> >
> >
> > Knut Wannheden schrieb:
> > > All,
> > >
> > > I've been experimenting with XML module descriptor caching as a means
> > > to reduce the registry construction phase. I intended to implement
> > > this as a specialized ModuleDescriptorProvider which can save and load
> > > a ModuleDescriptor object to / from a file.
> > >
> > > My first attempt at this was to just have all the affected classes
> > > (*Descriptor, *Rule classes, etc.) implement java.io.Serializable and
> > > then serialize the ModuleDescriptor object to a file using standard
> > > Java object serialization. Alas this didn't result in any significant
> > > performance gain.
> > >
> > > By implementing java.io.Externalizable I am sure some performance
> > > could be gained. But at the cost of some complexity. Also I'm
> > > wondering how much performance there is to gain by doing this.
> > >
> > > I was wondering if any of you had any other ideas on how to approach
> > > this. E.g. use Javassist?
> > >
> > > Further, once we find a feasible caching technique I think we should
> > > also deliver this serialized form inside the jar files. E.g. a
> > > META-INF/hivemodule.xml.ser file. What do you think about that?
> > >
> > > Cheers,
> > >
> > > --knut
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: hivemind-dev-unsubscribe <at> jakarta.apache.org
> > > For additional commands, e-mail: hivemind-dev-help <at> jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-dev-unsubscribe <at> jakarta.apache.org
> > For additional commands, e-mail: hivemind-dev-help <at> jakarta.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Resolved: (HIVEMIND-85) Adds condtional inclusion of
sub-modules
Posted by "Knut Wannheden (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-85?page=all ]
Knut Wannheden resolved HIVEMIND-85:
------------------------------------
Fix Version: 1.1.2
1.2
Resolution: Fixed
Assign To: Knut Wannheden
> Adds condtional inclusion of sub-modules
> ----------------------------------------
>
> Key: HIVEMIND-85
> URL: http://issues.apache.org/jira/browse/HIVEMIND-85
> Project: HiveMind
> Type: Improvement
> Components: documentation, framework
> Versions: 1.1
> Reporter: Johan Lindquist
> Assignee: Knut Wannheden
> Priority: Minor
> Fix For: 1.1.2, 1.2
> Attachments: jakarta-hivemind-conditional-submodule.patch, jakarta-hivemind-conditional-submodule.tar.gz
>
> Provided patch (and tar bundle) adds conditionals support for sub-module descriptor elements. Included junit tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-85) Adds condtional inclusion of
sub-modules
Posted by "Johan Lindquist (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-85?page=comments#action_12367636 ]
Johan Lindquist commented on HIVEMIND-85:
-----------------------------------------
Any chance of getting this into the next version? The conditional inclusion of implementations and contributions are proving to be very powerful and this one [to me] feels like it would complete the inclusion feature quite nicely.
Cheers,
Johan
> Adds condtional inclusion of sub-modules
> ----------------------------------------
>
> Key: HIVEMIND-85
> URL: http://issues.apache.org/jira/browse/HIVEMIND-85
> Project: HiveMind
> Type: Improvement
> Components: documentation, framework
> Versions: 1.1
> Reporter: Johan Lindquist
> Priority: Minor
> Attachments: jakarta-hivemind-conditional-submodule.patch, jakarta-hivemind-conditional-submodule.tar.gz
>
> Provided patch (and tar bundle) adds conditionals support for sub-module descriptor elements. Included junit tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org