[prev in list] [next in list] [prev in thread] [next in thread]
List: geronimo-dev
Subject: Re: [DISCUSS] What are the most wanted features in final Geronimo 3.0
From: David Jencks <david_jencks () yahoo ! com>
Date: 2011-09-27 0:43:53
Message-ID: A2A00F4D-596E-408B-9C10-C33512C6B47F () yahoo ! com
[Download RAW message or body]
On Sep 24, 2011, at 6:45 AM, Ivan wrote:
> Hi, devs,
> Think that most of work of Geronimo 3.0 beta is done, and we will not introduce \
> some major changes, and seems that the only dependencies are some other third party \
> components. Now we could go ahead to have an overview for Geronimo 3.0. and what \
> features are most important in the 3.0. The items below is somewhat I would like to \
> see, and appreciate any comment. a. Server runtime side :
> a1. Now, we have issues while the same packages with different versions exported, \
> and in the deployment process, currently, a system property is introduced to \
> identify whether the fixed import version scope is used, e.g. \
> org.apache.***;version=[1.0,1.0] or org.apache.***;version=1.0. In the new OSGi \
> 4.3, the new resolver hook API should be helpful for this. a2. Remove the dynamic \
> import *, now we use it in two places, one is in the temp bundle in the deployment \
> process, and another is car package. a3. Use application scoped configuration, I \
> have mentioned it in the past, I really do not like so many system properties in \
> the server codes, there is a JIRA GERONIMO-5813 for this. With this, server will \
> have fine-grained configurations per module. a4. Reconsider EAR support, I am \
> thinking that we might still divide the EAR to n+1 bundles, although it is not \
> required by the Java EE spec. In some current application programming, it seems to \
> be a default mind. e.g. Recently, I just fixed an issue in MyFaces integration, as \
> it uses the classloader as the key for each web application. b. Web Service:
> b1. Improve Axis2 integration, now some parsing work is done each time while \
> starting up the application, e.g. build the endpoint structure. It is better to \
> have some metadata there, and actually, we have done this on web application, JSF \
> integration etc. b2. Provide a portlet for the web service, e.g. show web service \
> information per application, generate client artifacts on the fly etc. b3. Better \
> support for ws-security, I remembered that we have done some initial integration \
> for this in the past. c. Enable Jetty Assembly, most work should be on CXF side, I \
> guess. d. Cluster/Farm related features
> e. ActiveMQ integration improvement, we should provide a simple way for the end \
> users to configure the broker, and also add/remove brokers. f. WInk integration \
> improvement, e.g. GERONIMO-6122 g. Take advantage of more OSGi 4.3 new features, I \
> knew that we might use the new wiring API for calculating wired \
> bundles.
> ...
> I knew that David is working on some OSGi-friendly changes, and introduce the Karaf \
> features, some of the ideas above are required to consider those changes, anyway, \
> just some ideas, thoughts ? :-)
> --
What I would like for 3.0 is to get the work I've been doing to make the gbean \
framework more compatible with osgi into trunk and to use the tx manager in my \
sandbox. As part of this I moved away from using xmlbeans for geronimo plans.
If we get this to work I'd like to make all the deployers into extenders: I already \
did this in the sandbox tm. Generally I think the way to do this is to build an info \
tree (like we do for web and ejb apps) and set up the application from it. For \
"precompiled" apps we can write these into the bundle, for plain bundles we can write \
these into the data area, and for new bundles just generate them. Again the sandbox \
tm does this.
I think this would provide an architecturally satisfactory base on which to add \
functionality and also gradually replace gbeans with other styles of osgi services.
However I think this will be a lot of work and think if we all work on it we might \
get it done by the end of the year.
thanks
david jencks
> Ivan
[Attachment #3 (unknown)]
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; "><br><div><div>On Sep 24, 2011, at 6:45 AM, \
Ivan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi, \
devs, <div> Think that most of work of Geronimo 3.0 beta is done, \
and we will not introduce some major changes, and seems that the only dependencies \
are some other third party components. Now we could go ahead to have an overview for \
Geronimo 3.0. and what features are most important in the 3.0.</div>
<div> The items below is somewhat I would like to see, and appreciate \
any comment.</div><div> a. Server runtime side :</div><div> \
a1. Now, we have issues while the same packages with different versions \
exported, and in the deployment process, currently, a system property is introduced \
to identify whether the fixed import version scope is used, e.g. \
org.apache.***;version=[1.0,1.0] or org.apache.***;version=1.0. In the new OSGi 4.3, \
the new resolver hook API should be helpful for this.</div>
<div> a2. Remove the dynamic import *, now we use it in \
two places, one is in the temp bundle in the deployment process, and another is car \
package.</div><div> a3. Use application scoped \
configuration, I have mentioned it in the past, I really do not like so many system \
properties in the server codes, there is a JIRA <span style="font-family:arial, \
FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"><a href="https://issues.apache.org/jira/browse/GERONIMO-5813" \
style="color:rgb(60, 120, 181);text-decoration:none" \
target="_blank">GERONIMO-5813</a> for this. With this, server will have \
fine-grained configurations per module.</span></div>
<div><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> a4. Reconsider EAR support, I am \
thinking that we might still divide the EAR to n+1 bundles, although it is not \
required by the Java EE spec. In some current application programming, it seems to be \
a default mind. e.g. Recently, I just fixed an issue in MyFaces \
integration,</span></div> <div><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> as it uses \
the classloader as the key for each web application.</span></div> <div><span \
style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> b. Web Service:</span></div> <div><span \
style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> b1. Improve Axis2 integration, now some \
parsing work is done each time while starting up the application, e.g. build the \
endpoint structure. It is better to have some metadata there, and actually, we have \
done this on web application, JSF integration etc.</span></div>
<div><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> b2. Provide a portlet for the web \
service, e.g. s</span><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)">how web service information per application, g</span><span \
style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)">enerate client artifacts on the fly etc.</span></div>
<div><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> b3. Better support for \
ws-security, I remembered that we have done some initial integration for this in the \
past.</span></div> <div><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> c. </span><span class="Apple-style-span" \
style="font-family: arial, FreeSans, Helvetica, sans-serif; font-size: 12px; \
line-height: 15px; white-space: nowrap; background-color: rgb(240, 240, 240); \
">Enable Jetty Assembly, most work should be on CXF side, I guess.</span></div> \
<div><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> d. Cluster/Farm related \
features</span></div><div><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> e. ActiveMQ integration improvement, we should provide \
a simple way for the end users to configure the broker, and also add/remove \
brokers.</span></div> <div><span style="font-family:arial, FreeSans, Helvetica, \
sans-serif;font-size:12px;line-height:15px;white-space:nowrap;background-color:rgb(240, \
240, 240)"> f. WInk integration improvement, \
e.g. </span><span class="Apple-style-span" style="font-family: arial, \
FreeSans, Helvetica, sans-serif; font-size: 12px; line-height: 15px; white-space: \
nowrap; background-color: rgb(240, 240, 240); "><a \
href="https://issues.apache.org/jira/browse/GERONIMO-6122" style="color: rgb(60, 120, \
181); cursor: pointer; text-decoration: none; ">GERONIMO-6122</a></span></div> \
<div> g. Take advantage of more OSGi 4.3 new features, I knew that we \
might use the new wiring API for calculating wired bundles.</div><div> \
...</div><div> I knew that David is working on some OSGi-friendly \
changes, and introduce the Karaf features, some of the ideas above are required to \
consider those changes, anyway, just some ideas, thoughts ? :-)</div> <div><div>-- \
<br></div></div></blockquote><div><br></div><div>What I would like for 3.0 is to get \
the work I've been doing to make the gbean framework more compatible with osgi into \
trunk and to use the tx manager in my sandbox. As part of this I moved away \
from using xmlbeans for geronimo plans.</div><div><br></div><div>If we get this to \
work I'd like to make all the deployers into extenders: I already did this in the \
sandbox tm. Generally I think the way to do this is to build an info tree (like \
we do for web and ejb apps) and set up the application from it. For \
"precompiled" apps we can write these into the bundle, for plain bundles we can write \
these into the data area, and for new bundles just generate them. Again the \
sandbox tm does this.</div><div><br></div><div>I think this would provide an \
architecturally satisfactory base on which to add functionality and also gradually \
replace gbeans with other styles of osgi services.</div><div><br></div><div>However I \
think this will be a lot of work and think if we all work on it we might get it done \
by the end of the year.</div><div><br></div><div>thanks</div><div>david \
jencks</div><div><br></div><br><blockquote type="cite"><div><div>Ivan<br> \
</div></div> </blockquote></div><br></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic