CORBA and GSSUP fix -- please review
So it turns out our GSSUP token encoder set the username to [EMAIL PROTECTED] and the GSSUP token decoder did not lop off the @domain part, so Geronimo could not talk to itself using GSSUP. I changed the token encoder to just pass the username straight through -- there is a separate field in the token that holds the domain, after all, so mangling the username did not seem to make much sense. Just want to make a note of this in case someone thinks it should be changed the other way (that is, the GSSUP token encoder should send [EMAIL PROTECTED] and the GSSUP token decoder should lop off and ignore the @domain part, or compare the @domain to the domain that is sent in the other field). Thanks, Aaron P.S. Actually the GSSUP token encoder set the username to [EMAIL PROTECTED] due to an additional bug in the dynamic GSSUP configuration, so I gather no one's actually used this code before. :)
[jira] Commented: (GERONIMO-1590) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1590?page=comments#action_12365829 ] Aaron Mulder commented on GERONIMO-1590: Fixed in OpenEJB branch corresponding to Geronimo 1.0 Still needs to be implemented in OpenEJB HEAD (where the proposal above doesn't work due to refactoring of the classes) > CORBA for EJB with Local interface only causes NPE > -- > > Key: GERONIMO-1590 > URL: http://issues.apache.org/jira/browse/GERONIMO-1590 > Project: Geronimo > Type: Bug > Components: CORBA, OpenEJB > Versions: 1.0 > Reporter: Aaron Mulder > Fix For: 1.0.1, 1.1 > > I have an EJB with a local interface and I tried applying CORBA settings. It > blows up during deployment. My guess is that it wants a remote interface to > be there, but somehow, the checks in StandardServant:126 are not working and > the interface just comes up as null. > Caused by: java.lang.NullPointerException > at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593) > at org.openejb.corba.util.Util.getAllMethods(Util.java:815) > at org.openejb.corba.util.Util.iiopMap(Util.java:608) > at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604) > at org.openejb.corba.StandardServant.(StandardServant.java:135) > at org.openejb.corba.StandardServant.(StandardServant.java:116) > at org.openejb.corba.Adapter.(Adapter.java:100) > ... 67 more -- 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
[jira] Commented: (GERONIMO-1617) Unable to look up CORBA EJB with no JNDI Name
[ http://issues.apache.org/jira/browse/GERONIMO-1617?page=comments#action_12365827 ] Aaron Mulder commented on GERONIMO-1617: Fixed in OpenEJB branch corresponding to Geronimo 1.0 Still needs to be implemented in OpenEJB HEAD > Unable to look up CORBA EJB with no JNDI Name > - > > Key: GERONIMO-1617 > URL: http://issues.apache.org/jira/browse/GERONIMO-1617 > Project: Geronimo > Type: Bug > Components: OpenEJB, CORBA > Versions: 1.0 > Reporter: Aaron Mulder > Fix For: 1.1, 1.0.1 > > If you configure an EJB for CORBA but have no JNDI name declared, it doesn't > seem possible to look it up in the CORBA naming service. The deployer should > throw an exception in this case. -- 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
[jira] Closed: (GERONIMO-1616) CSS GSSUP token encoding sets username to [EMAIL PROTECTED] but decoding does not reverse that
[ http://issues.apache.org/jira/browse/GERONIMO-1616?page=all ] Aaron Mulder closed GERONIMO-1616: -- Resolution: Fixed Assign To: Aaron Mulder Fixed in OpenEJB branch and head > CSS GSSUP token encoding sets username to [EMAIL PROTECTED] but decoding does > not reverse that > > > Key: GERONIMO-1616 > URL: http://issues.apache.org/jira/browse/GERONIMO-1616 > Project: Geronimo > Type: Bug > Components: CORBA, OpenEJB > Versions: 1.0 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Fix For: 1.0.1, 1.1 > > When a dynamic GSSUP client authenticates, the username sent to the server is > [EMAIL PROTECTED], but when the GSSUP server decodes the token, it takes the > whole string as the username, and therefore authentication from Geronimo to > Geronimo using dynamic GSSUP always fails. > Since there's a separate field in the GSSUP token for the domain name, I > assume the username should just be the username and not [EMAIL PROTECTED] -- 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
[jira] Closed: (GERONIMO-1615) CSS GSSUP dynamic auth sends domain name as username
[ http://issues.apache.org/jira/browse/GERONIMO-1615?page=all ] Aaron Mulder closed GERONIMO-1615: -- Resolution: Fixed Assign To: Aaron Mulder Fixed in OpenEJB branch and head > CSS GSSUP dynamic auth sends domain name as username > > > Key: GERONIMO-1615 > URL: http://issues.apache.org/jira/browse/GERONIMO-1615 > Project: Geronimo > Type: Bug > Components: CORBA, OpenEJB > Versions: 1.0 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Fix For: 1.0.1, 1.1 > > The dynamic GSSUP authentication client sends the domain name as the > username, as well as as the target domain name. The username is not sent at > all. > e.g. user logs in as foo with password bar to domain test. > CORBA server receives request for user [EMAIL PROTECTED] with password bar > and domain test. -- 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
[jira] Created: (GERONIMO-1617) Unable to look up CORBA EJB with no JNDI Name
Unable to look up CORBA EJB with no JNDI Name - Key: GERONIMO-1617 URL: http://issues.apache.org/jira/browse/GERONIMO-1617 Project: Geronimo Type: Bug Components: OpenEJB, CORBA Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1, 1.0.1 If you configure an EJB for CORBA but have no JNDI name declared, it doesn't seem possible to look it up in the CORBA naming service. The deployer should throw an exception in this case. -- 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
[jira] Commented: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
[ http://issues.apache.org/jira/browse/GERONIMO-1614?page=comments#action_12365819 ] erik daughtrey commented on GERONIMO-1614: -- FixTextLines does append an extra line. There's some possibility that this is causing the problem. As I recall, the specific problem was with the xml files in: config-store//geronimo-console-framework-1.0.1-SNAPSHOT.war/WEB-INF/data > Installer - Console portal servlet fails to load properly after install > --- > > Key: GERONIMO-1614 > URL: http://issues.apache.org/jira/browse/GERONIMO-1614 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-console-textline-fix.patch > > The FixTextLines function "fixes" all CRLFs in xml and other file types > across the Geronimo > install tree. Apparently, the version of the Pluto portal being used does > not > appreciate its XML files being adjusted. > The fix will cause FixTextLines to bypass the config-store directory when > fixing line endings. > Additionally the fix blends in some new error/trace logging functionality > which may > be enabled with -DTRACE=true on the installer command line. -- 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
Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
On Feb 9, 2006, at 3:28 PM, John Sisson wrote: Hiram Chirino wrote: Hi, I was just looking into these issues in regard to the activemq and servicemix sites. I really do like confluence a ton and would eventually like to see be part of the ASF infrastructure. What I would like is to just export the confluence content to a static site. This would allow us to also enhance/style/aggregate the content during the export so that nice looking project websites are the results. Can exporting to a static site be done today, or do tools need to be written? Even if we do this to overcome the Confluence performance concerns won't that mean we still need to retain a Wiki for users to use (hopefully without duplicated content) and therefore still have Moin Moin running for Geronimo (until Confluence performance concerns are addressed)? You really need to get on infra@, there is some great info in the discussions there. Likewise any insights on this list do nothing for the conversations there. On Feb 5, 2006, at 2:27 PM, Jeff Turner wrote: Here's how I see things going forward.. 1) Towards Confluence as a direct MoinMoin alternative Infrastructure@ want some decent benchmarks demonstrating that Confluence can survive sustained heavy load (ala MoinMoin) and/or spikes (slashdot). Noel rightly says caching is essential. Briefly experimenting with 'ab -c 100 -n 1000' suggests that Confluence's internal caching may be enough. I'll ask the Confluence team if they can produce some benchmarks. 2) Confluence as doc staging/development environment There are various ways to suck content from Confluence to a live site: - Maven has Doxia in development. - Codehaus have a Perl script (Confluenza) which sucks down content via XML-RPC to build their website. - Pier is working on a Confluence plugin that saves static HTML. - Anyone can rig up a script using Confluence's XML-RPC/SOAP API. Confluence does not have to be running on ASF hardware for its use as a doc staging environment. Some projects might use the Codehaus Confluence, some use http://opensource2.atlassian.com/confluence/oss/. It would be nice if the ASF had an internal Confluence installation for doc staging, and that's what I proposed Atlassian would sponsor a box (partly) for. -David
[jira] Commented: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
[ http://issues.apache.org/jira/browse/GERONIMO-1614?page=comments#action_12365818 ] John Sisson commented on GERONIMO-1614: --- Eric, can you give some more detail on the file that Pluto was having problems with and the symptoms. Doing a quick search of the pluto mailing lists did not pick up anything obvious when searching for 'CRLF'. I think we need a better understanding of the problem, as we also have the geronimo-assembly-plugin jelly code do fixcrlf processing also. So in theory if there is an issue with CRLFs in XML files, then this would be an issue on windows if you use the geronimo zip distribution. > Installer - Console portal servlet fails to load properly after install > --- > > Key: GERONIMO-1614 > URL: http://issues.apache.org/jira/browse/GERONIMO-1614 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-console-textline-fix.patch > > The FixTextLines function "fixes" all CRLFs in xml and other file types > across the Geronimo > install tree. Apparently, the version of the Pluto portal being used does > not > appreciate its XML files being adjusted. > The fix will cause FixTextLines to bypass the config-store directory when > fixing line endings. > Additionally the fix blends in some new error/trace logging functionality > which may > be enabled with -DTRACE=true on the installer command line. -- 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
[jira] Updated: (GERONIMO-1585) Web app security on /* causes deployment exception
[ http://issues.apache.org/jira/browse/GERONIMO-1585?page=all ] Anita Kulshreshtha updated GERONIMO-1585: - Environment: Geronimo 1.0 with Jetty and tomcat (was: Geronimo 1.0 with Jetty) > Web app security on /* causes deployment exception > -- > > Key: GERONIMO-1585 > URL: http://issues.apache.org/jira/browse/GERONIMO-1585 > Project: Geronimo > Type: Bug > Components: web, security > Versions: 1.0 > Environment: Geronimo 1.0 with Jetty and tomcat > Reporter: Aaron Mulder > Priority: Critical > Fix For: 1.0.1, 1.1 > > Deploying a web app with the following security block causes a deployment > error: > > > All Pages > /* > GET > POST > PUT > > > User > > > Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet > 2.4 spec). > The error is: > org.apache.geronimo.common.DeploymentException: Unable to initialize > webapp GBean > at > org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) > ... > Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the > URLPatternSpec cannot match the first URLPattern > at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:54) > at > javax.security.jacc.WebResourcePermission.(WebResourcePermission.java:54) > at > org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) > at > org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) > ... 70 more > Changing the url-pattern to / fixes the problem, but it seems to me that /* > ought to work too. -- 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
Re: [jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
Aaron,
I have unit tested this on jetty and it is working
on tomcat-server. The change is too small for a patch.
Thanks
Anita
--- "Anita Kulshreshtha (JIRA)"
wrote:
> [
>
http://issues.apache.org/jira/browse/GERONIMO-1585?page=comments#action_12365630
> ]
>
> Anita Kulshreshtha commented on GERONIMO-1585:
> --
>
> Aaron could you please add a line pat = "/" as shown
> here in o.a.g.security.util.URLPattern and test if
> your app works.
>
> public URLPattern(String pat) {
> if (pat == null)
> t..
> if (pat.length() == 0)
> ...
>
> if (pat.equals("/") || pat.equals("/*")) {
> type = DEFAULT;
> pat = "/";
> <--new line
> . .}else
>
>
> > Web app security on /* causes deployment exception
> > --
> >
> > Key: GERONIMO-1585
> > URL:
> http://issues.apache.org/jira/browse/GERONIMO-1585
> > Project: Geronimo
> > Type: Bug
> > Components: web, security
> > Versions: 1.0
> > Environment: Geronimo 1.0 with Jetty
> > Reporter: Aaron Mulder
> > Priority: Critical
> > Fix For: 1.0.1, 1.1
>
> >
> > Deploying a web app with the following security
> block causes a deployment error:
> >
> >
> > All
> Pages
> > /*
> > GET
> > POST
> > PUT
> >
> >
> > User
> >
> >
> > Note this is essentially right out of the spec
> (see SRV.12.8.2 in the Servlet 2.4 spec).
> > The error is:
> >
> org.apache.geronimo.common.DeploymentException:
> Unable to initialize webapp GBean
> > at
>
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
> > ...
> > Caused by: java.lang.IllegalArgumentException:
> Qualifier patterns in the URLPatternSpec cannot
> match the first URLPattern
> > at
>
javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:54)
> > at
>
javax.security.jacc.WebResourcePermission.(WebResourcePermission.java:54)
> > at
>
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
> > at
>
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
> > ... 70 more
> > Changing the url-pattern to / fixes the problem,
> but it seems to me that /* ought to work too.
>
> --
> 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
>
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[jira] Created: (GERONIMO-1616) CSS GSSUP token encoding sets username to [EMAIL PROTECTED] but decoding does not reverse that
CSS GSSUP token encoding sets username to [EMAIL PROTECTED] but decoding does not reverse that Key: GERONIMO-1616 URL: http://issues.apache.org/jira/browse/GERONIMO-1616 Project: Geronimo Type: Bug Components: CORBA, OpenEJB Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 When a dynamic GSSUP client authenticates, the username sent to the server is [EMAIL PROTECTED], but when the GSSUP server decodes the token, it takes the whole string as the username, and therefore authentication from Geronimo to Geronimo using dynamic GSSUP always fails. Since there's a separate field in the GSSUP token for the domain name, I assume the username should just be the username and not [EMAIL PROTECTED] -- 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
[jira] Created: (GERONIMO-1615) CSS GSSUP dynamic auth sends domain name as username
CSS GSSUP dynamic auth sends domain name as username Key: GERONIMO-1615 URL: http://issues.apache.org/jira/browse/GERONIMO-1615 Project: Geronimo Type: Bug Components: CORBA, OpenEJB Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 The dynamic GSSUP authentication client sends the domain name as the username, as well as as the target domain name. The username is not sent at all. e.g. user logs in as foo with password bar to domain test. CORBA server receives request for user [EMAIL PROTECTED] with password bar and domain test. -- 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
Re: Issues dealing with ThreadPool
It's not clear that there's anything specific to thread pools here.
Can you post your entire GBean class, or at least all constructors,
getters, setters, and everything related to creating the GBeanInfo?
It seems like the GBean metadata may be out of sync with the actual
class definition.
Also, did you solve your previous problem with the j2eeTypes (or at
least, is this the same problem)?
Thanks,
Aaron
On 2/9/06, Nelson Perez <[EMAIL PROTECTED]> wrote:
>
>
> Hi all,
>
> I am trying to use a ThreadPool in my application. In the plan.xml file, I
> have:
>
> class="org.apache.geronimo.pool.ThreadPool">
> 5000
> 10
> DefaultThreadPool
>
>
>
>
>
>
>
>
>
> DefaultThreadPool
>
>
>
>
>
>
> And on the file MyGBean.java I have a reference to it:
>
> infoFactory.addReference("Executor",org.apache.geronimo.pool.ThreadPool.class,NameFactory.GERONIMO_SERVICE);
>
> ant it is set via setter injection as follows:
>
>
> public void setExecutor( org.apache.geronimo.pool.ThreadPool Executor ){
> this.Executor = Executor;
> }
>
>
> Yet, it is not working, I get a "java.lang.IllegalArgumentException: cannot
> find matching method/constructor" so MyGBean fails to start because
> (according to the log) :
>
>
> 12:38:40,328 ERROR [GBeanInstanceState] Error while starting; GBean is now
> in the FAILED state:
> objectName="geronimo.server:J2EEApplication=null,J2EEModule=ibmtask/IBMTask,J2EEServer=geronimo,j2eeType=GBean,name=MyGBean"
> java.lang.IllegalArgumentException: Cannot find matching method/constructor
> at
> org.apache.geronimo.pool.ThreadPool$$EnhancerByCGLIB$$a5ca88c4$$FastClassByCGLIB$$4a3acb71.newInstance()
> at net.sf.cglib.reflect.FastClass.newInstance(FastClass.java:91)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:211)
> at
> org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:108)
> at
> org.apache.geronimo.gbean.runtime.GBeanSingleReference.start(GBeanSingleReference.java:79)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:863)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
> at
> org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315)
> at
> org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173)
> at
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142)
> at
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
> at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125)
> at
> org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
> at
> org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBe
Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
Hiram Chirino wrote: Hi, I was just looking into these issues in regard to the activemq and servicemix sites. I really do like confluence a ton and would eventually like to see be part of the ASF infrastructure. What I would like is to just export the confluence content to a static site. This would allow us to also enhance/style/aggregate the content during the export so that nice looking project websites are the results. Can exporting to a static site be done today, or do tools need to be written? Even if we do this to overcome the Confluence performance concerns won't that mean we still need to retain a Wiki for users to use (hopefully without duplicated content) and therefore still have Moin Moin running for Geronimo (until Confluence performance concerns are addressed)? Regards, John Regards, Hiram On Feb 3, 2006, at 10:40 AM, Rodent of Unusual Size wrote: Forwarding to the dev@ list with permission. This is where it belongs. --#kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" See: http://confluence.atlassian.com/display/DOC/Running+Confluence+Behind+a+Cach ing+Proxy+Server The comment: "The main problem with the reverse-proxy solution is that every Confluence page is built dynamically for whichever user is currently accessing it." is a typical indicator of a common problem in many dynamic content systems, which all too often neglect the fact that 99.999+% of all traffic is going to be relatively static and anonymous. Dynamic does not mean ephemeral, and that distinction is missed all too often. The facts are that most Wiki access is anonymous, and Wiki content is almost entirely static and should be cachable. Confluence intentionally breaks caches, and that behavior needs to be fixed. There are a number of possible solutions. One way, and just a simple one, since there are others, would be for anonymous and authenticated access could have different URLs, e.g., mydomain.tld/confluence/anon/ for the public, and mydomain.tld/confluence/auth/ for authenticated users. That would permit the vast majority of accesses to be cached. "WAIT", you say, "What about when someone edits the page under the /auth/ path? Won't that cause a problem for viewers in the /anon/ path?" Not if the URLs are properly designed, and the system is supporting Conditional Get. The /anon/ path should be handling Conditional Get based upon the timestamp of the page resource. So most GET requests will simply return 304, unless the page has been changed, in which case the updated resource can be returned and cached. So these are technical issues (Joshua Slive outlined other, related, ones), and the ball has been in Atlassian's court to provide some resolution. --- Noel
Is the list of Geronimo PMC members listed on the Geronimo website somewhere?
We have a committers link on the http://geronimo.apache.org/ page, but I can't find any PMC list. Shouldn't we have one? Thanks, John
Re: Geronimo Web site update
Great work, Hernan! Its good to see you organizing stuff too. Our team quickly ran through the site. Here are our initial comments on the Apache Geronimo web site we reviewed located here: http://people.apache.org/~hogstrom/website 1. The black border around the bar on the left side makes the navigation area look really dark. Everyone here thought we should either change the border color to the light blue (to match the same as the header for the table). Or else make the left side look more like a bar and border white like in the mock up. http://people.apache.org/~hogstrom/website/contributors.html (contributors table) http://people.apache.org/~bsnyder/geronimo/site/ http://people.apache.org/~hogstrom/website/schemas.html On these examples, it makes the table look a little less dark. The nav bar would likely look cleaner and people would still be able to quickly identify it as a nav bar. Maybe the way Hernan did it with a thinner light blue border is the way to go for a site with only two columns instead of three. 2. The title for each area of the navigation bar is pushed slightly over to the left of the table. Perhaps adding some cell padding between table and font on the left menu bar would be helpful. 3. Same thing, between the left nav bar and the main body table. Adding a little space would likely help. 4. There is not really a need for bullets on the navigation bar on the left. Most users will recognize this as a navigation bar and won't need the bullet points. The bullet points are typically used for items in a series within a document, outline, or text, rather than in web navigation. In our mockup, we had these on the right side for article highlights or key Geronimo news. 5. On my Firefox install, the font looks kind of like a Serrif Font instead of a Sans Seriff Font - Seriff fonts don't modern, ie they evoke images of offline stuff like newspapers, type, books, etc instead of the web and modern stuff. (We suggest Verdana, Helvetica, Arial, but those are just a few.) We checked it on some other computers / browsers, and the fonts were good (Serrif). Might be something to check, but no big deal. Maybe my Firefix install is quirky. 6. On our mockup, we made it with 3 columns. The third column might be helpful for reading. The main reason why we made it a three column site was that it is difficult to read the text if it floats all the way over to the left, especially on a short page. We realize that perhaps 3 columns might be be hard to do in the content management system, though. Perhaps it is something to do in the next version of the web site. 7. In the sections where there is a blue bar running horizontally across the screen, it might help to slightly reduce the space between the header title text and the bar - maybe just a little bit. Those are a few of our suggestions / comments. There are also a few broken links, but those are easy to find. Anyway, Hernan has put this together quickly and admirably. Let me know if you guys need any more feedback or graphics. I'm sure other people will have some valuable comments as well. Glenn Hernan Cunico wrote: Hi All, I created a JIRA with the new Web site based on the template from EPIQ. So far, although I mainly focused on the template I also edited some of the content. I have not modified the build method so it still uses ant/anakia. Please send your comments and suggestions. https://issues.apache.org/jira/browse/GERONIMO-1611 Cheers! Hernan
Issues dealing with ThreadPool
Hi all,
I am trying to use a ThreadPool in my application. In the plan.xml file, I
have:
class="org.apache.geronimo.pool.ThreadPool">
5000
10
DefaultThreadPool
DefaultThreadPool
And on the file MyGBean.java I have a reference to it:
infoFactory.addReference("Executor",org.apache.geronimo.pool.ThreadPool.class,NameFactory.GERONIMO_SERVICE);
ant it is set via setter injection as follows:
public void setExecutor( org.apache.geronimo.pool.ThreadPool Executor ){
this.Executor = Executor;
}
Yet, it is not working, I get a "java.lang.IllegalArgumentException: cannot
find matching method/constructor" so MyGBean fails to start because
(according to the log) :
12:38:40,328 ERROR [GBeanInstanceState] Error while starting; GBean is now
in the FAILED state:
objectName="geronimo.server:J2EEApplication=null,J2EEModule=ibmtask/IBMTask,J2EEServer=geronimo,j2eeType=GBean,name=MyGBean"
java.lang.IllegalArgumentException: Cannot find matching method/constructor
at
org.apache.geronimo.pool.ThreadPool$$EnhancerByCGLIB$$a5ca88c4$$FastClassByCGLIB$$4a3acb71.newInstance()
at net.sf.cglib.reflect.FastClass.newInstance(FastClass.java:91)
at
org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.createProxy(BasicProxyManager.java:211)
at
org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:108)
at
org.apache.geronimo.gbean.runtime.GBeanSingleReference.start(GBeanSingleReference.java:79)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:863)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
at
org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315)
at
org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173)
at
org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142)
at
org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125)
at
org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
at
org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117)
at
mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219)
at sun.reflect.GeneratedMethodAccessor149.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34)
at
mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99)
at
mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31)
at
mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:90)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Unknown Source)
at mx4j.remote.MX4JRemoteU
Patterns dont match
Hi all, I am trying to run a sample application and I get the following error on the log file: 00:17:18,234 INFO [BPrinterGBean] BPrinterGBean has started 00:17:18,234 INFO [BPrinterGBean] geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=gbean2 00:17:18,250 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=MyGBean because no targets are running for reference Executor matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=null,name=DTP 00:17:18,250 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=MyGBean because no targets are running for reference APrinter matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=null,name=gbean1 00:17:18,250 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=MyGBean because no targets are running for reference BPrinter matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=null,name=gbean2 00:17:18,250 INFO [APrinterGBean] APrinterGBean has started 00:17:18,250 INFO [APrinterGBean] geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=gbean1 As you can see, clearly the patterns dont match because in one case we have j2eeType=null and in the other we have j2eeType=GBean. How can I set the j2eeType to GBean so that the patter can be matched ? Also, how can I be sure that the GBeans get loaded in the proper order ? In this case, the MyGBean has references to the three other GBeans: BPrinterGBean, APrinterGBean and DTP (Default Thread Pool). As you can read in the log file, only two GBeans (AprinterGBean and BPrinterGBean) get loaded and started, but not DTP and MyGBean. The plan looks as follows: http://geronimo.apache.org/xml/ns/deployment"; configId="sampleTask/Sample" > samples sampleTask 1.0 15000 10 DTP gbean1 gbean2 DTP BTW, is there a better place to post this issue ? Any help is appreciated! Thanks, Nelson. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Patterns dont match -- j2eeType
Hi all, I am trying to run a sample application and I get the following error on the log file: 00:17:18,234 INFO [BPrinterGBean] BPrinterGBean has started 00:17:18,234 INFO [BPrinterGBean] geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=gbean2 00:17:18,250 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=MyGBean because no targets are running for reference Executor matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=null,name=DTP 00:17:18,250 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=MyGBean because no targets are running for reference APrinter matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=null,name=gbean1 00:17:18,250 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=MyGBean because no targets are running for reference BPrinter matching the patterns geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=null,name=gbean2 00:17:18,250 INFO [APrinterGBean] APrinterGBean has started 00:17:18,250 INFO [APrinterGBean] geronimo.server:J2EEApplication=null,J2EEModule=sampleTask/Sample,J2EEServer=geronimo,j2eeType=GBean,name=gbean1 As you can see, clearly the patterns dont match because in one case we have j2eeType=null and in the other we have j2eeType=GBean. How can I set the j2eeType to GBean so that the patter can be matched ? Also, how can I be sure that the GBeans get loaded in the proper order ? In this case, the MyGBean has references to the three other GBeans: BPrinterGBean, APrinterGBean and DTP (Default Thread Pool). As you can read in the log file, only two GBeans (AprinterGBean and BPrinterGBean) get loaded and started, but not DTP and MyGBean. The plan looks as follows: http://geronimo.apache.org/xml/ns/deployment"; configId="sampleTask/Sample" > samples sampleTask 1.0 15000 10 DTP gbean1 gbean2 DTP Any help is appreciated! Thanks, Nelson. Nelson Perez. "Things should be made as simple as possible, but no simpler." -- Albert Einstein
Re: CORBA Incubation setup procedures
Hi Ken, I reviewed the proposal and yeah, it looks good to me. (non-binding) CORBA is a huge piece of work and I'm not surprised that it takes 22. I'd be surprised if the number of initial committers were less than 13. (random number generator 6..18) Craig On Feb 8, 2006, at 5:41 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan D. Cabrera wrote: I think I need: * SVN o http://svn.apache.org/repos/asf/incubator/yoko * Jira * Mailing lists o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] Hang on a moment. I see that Geronimo is cool with it, but I don't see any discussion of this proposal on [EMAIL PROTECTED] just the message saying that Geronimo wants to sponsor it. Before we start setting things up, I'd really like to call for some opinions about the proposal from *outside* the sponsoring TLP. Alan's message points out that the proposal is at http://wiki.apache.org/incubator/CorbaProposal Anyone on general@incubator.apache.org have any comments to make on the proposal? Even just 'yeah, looks good to me' ? Mine is that 22 seems a rather large number (!) of initial committers for a podling.. If nothing further comes from this message within a couple of days, let's go ahead. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+qdxZrNPMCpn3XdAQKjrAP9GlZgvfc2GYDu8SsKYtPBCPzAL8rHLjOL UwhEDqZPlvtQC8jpWIkxOrsUiZw+p3YhMzRkNrR5odmyGcdEsZFy2epSz7EQhoMB z4jR/ABCgH5pOpxunPfW+apyCcqC6xmPdt5KKnRWQDOdNpr15BWZLATZKXEJaiyY lhRxBQH4WPs= =dfIM -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: CORBA Incubation setup procedures
Ken wrote: > Before we start setting things up, I'd really like to > call for some opinions about the proposal from *outside* > the sponsoring TLP. Please see the threads around "Changes to Incubator Process(es)" from January. There has been some call for the Incubator PMC to have more control over what comes into the Incubator, but not everyone agrees. And in my view it would take some clarification from the Board to change the current approach. Jim was going to take that up, or so I had the impression, but I don't know if the Board has yet considered the issue, or simply does not see fit to comment. A CORBA ORB can be a fairly interesting beast, although I'm all for elegant simplicity. Multiple realms of parts: the ORB, itself; skeleton and stub management; IDL and DII support; CSIv2 and IIOP protocols; COSNaming (should be tied into the Apache Directory Server); etc. For those who didn't sit on the CORBA Task Force, or aren't otherwise actively aware of the technology, a simple introduction is http://www.omg.org/gettingstarted/corbafaq.htm. As of J2EE 1.3 and later, certain parts of CORBA (specifically, CSIv2 and COSNaming) are mandatory, so I can see why Geronimo would be interested. However, according to the the proposal, a complete CORBA ORB is proposed: This proposal is to build a compliant OMG CORBA server. The developer community will take [the initial contributions] as input and produce the best possible CORBA server In light of that, this could end up heading for TLP status, perhaps with other people who want to work on the rest of the OMG COS. --- Noel
[jira] Commented: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=comments#action_12365783 ] erik daughtrey commented on GERONIMO-1518: -- The fix for JIRA 1614 fixes the problem with the console. The fix for copying the dependencies by hand is still in the works. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor-1.0.1.patch, installer-jar-refactor.patch > > Change this issue to only apply to 1.0.1. Another issue will be created > to address 1.1. -- 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
[jira] Updated: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
[ http://issues.apache.org/jira/browse/GERONIMO-1614?page=all ] erik daughtrey updated GERONIMO-1614: - Attachment: installer-console-textline-fix.patch Change to bypass target install's config-store directory when fixing line endings. Added trace feature. > Installer - Console portal servlet fails to load properly after install > --- > > Key: GERONIMO-1614 > URL: http://issues.apache.org/jira/browse/GERONIMO-1614 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0.1, 1.1 > Reporter: erik daughtrey > Attachments: installer-console-textline-fix.patch > > The FixTextLines function "fixes" all CRLFs in xml and other file types > across the Geronimo > install tree. Apparently, the version of the Pluto portal being used does > not > appreciate its XML files being adjusted. > The fix will cause FixTextLines to bypass the config-store directory when > fixing line endings. > Additionally the fix blends in some new error/trace logging functionality > which may > be enabled with -DTRACE=true on the installer command line. -- 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
[jira] Created: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
Installer - Console portal servlet fails to load properly after install --- Key: GERONIMO-1614 URL: http://issues.apache.org/jira/browse/GERONIMO-1614 Project: Geronimo Type: Bug Components: installer Versions: 1.0.1, 1.1 Reporter: erik daughtrey The FixTextLines function "fixes" all CRLFs in xml and other file types across the Geronimo install tree. Apparently, the version of the Pluto portal being used does not appreciate its XML files being adjusted. The fix will cause FixTextLines to bypass the config-store directory when fixing line endings. Additionally the fix blends in some new error/trace logging functionality which may be enabled with -DTRACE=true on the installer command line. -- 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
Re: Test strategy
Oops.. sorry. This should have helped. http://www.mail-archive.com/dev@geronimo.apache.org/msg16726.html Cheers Prasad On 2/9/06, David Blevins <[EMAIL PROTECTED]> wrote: > On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote: > > > I have completed items 1 and 3 of the test strategy outlined above. > > With that we now have the geronimo-deployment-plugin in maven 2. > > What are items 1 and 3? Don't see an outline. > > -David > > > > I have now begun working on item 2 which is to create a separate > > itests sub-project that will act as a catchment of the itests from the > > various modules. Now this is what we should look into - have the > > itests subproject as a dependency of the Geronimo project, and include > > the tests during the integration-phase of the lifecycle in G's build. > > Yet keep it separate, and thus be able to run the itests against any > > G's distribution binary separately. This would be the best of both > > worlds. I'll investigate the possibility of doing so. > > > > Jason, it is at this point that I have begun looking at TestNG. I have > > some questions for you. > > - Have you used it yourself ? > > - How do you think it will fit into the picture I painted above where > > the testsuites will be contributed by folks from the the various > > modules ? > > - Do they all have to use TestNG then ? > > > > We need a framework that can perform system level tests 'coz that is > > what itests are at this point. > > > > Cheers > > Prasad > > > > On 1/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > >> Anyone thought about using TestNG? > >> > >> Its xml suite def and grouping support would be nice to define > >> these itest suites. > >> > >> --jason > >> > >> > >> -Original Message- > >> From: David Blevins <[EMAIL PROTECTED]> > >> Date: Mon, 30 Jan 2006 20:41:39 > >> To:dev@geronimo.apache.org > >> Subject: Re: Test strategy > >> > >> > >> On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote: > >>> I would like to solicit the views of others too like you and get > >>> their > >>> views and opinions. > >> > >> Great. I poked some other people in irc to get involved as well. > >> Here is hoping :) More input is going to make for a better > >> community supported solution. > >> > > - The tests can all be run or only a subset of suites can be run > > quite easily. > >>> > When you say "easily" do you mean by virtue of them being > separate or > some other idea? > >>> > >>> When I said we could run a subset of tests "easily" when the itests > >>> are run "on" assemblies, I meant that it would be relatively > >>> easier to > >>> selectively include/exclude tests (by categories) than when compared > >>> to doing the same if the itests are embedded with their modules. > >> > >> I think I follow what you mean. I guess the haze is in what you mean > >> by "embedded." > >> > >> As I'm not sure, I will just state in more specific terms that I have > >> never argued for putting the actual testing source code inside any > >> particular assembly module -- this code is big, bulky, has a lot of > >> deps itself and some pretty specific packaging needs. I have argued > >> for simply running thebig test suite during the lifecycle of an > >> assembly. > >> > >> Not sure if that is coming across well, or if it's being assumed that > >> since I've recommended running the integration tests on an assembly, > >> during the integration test phase of it's lifecycle, that the test > >> source of course must be in the assembly as well. I believe we agree > >> on keeping the test source in modules separate and organized. > >> > > - The tests will be grouped logically into suites or categories. > > Each > > individual test will fall in one of these suites. > >>> > Not sure of your usage of the word "test" in this sentence. In > junit > terms is that TestSuite, TestCase, or individual test method. Can > you clarify? > >>> > >>> I meant TestCase. For. eg, we could have a TestSuite called, > >>> "System" > >>> which will have test cases from many different modules. We could say > >>> that these form the core set of tests. If the System suite > >>> passed, we > >>> have somewhat of a stable binary with the caveat that all functions > >>> may not work. > >> > >> That is much clearer to me, thanks. I do like the sort of parent > >> module name you came up with of "System" too -- it's a keeper. > >> > >> At this point, I will note that it is possible put a single > >> SuperServerSystemTest.java TestSuite in the SuperServer assemblies > >> module (for example) that adds only the tests from the many different > >> test modules that apply to that assembly. > >> > >>> In summary, the cons of running the itests "on" assemblies is > >>> that it > >>> goes against the m2 lifecycle. And even though integration-test > >>> is an > >>> m2 lifecycle phase, we are not exploiting it's usage but calling it > >>> explicity again. The same has to be done for the deplo
Re: Test strategy
On Feb 9, 2006, at 9:10 AM, Prasad Kashyap wrote: I have completed items 1 and 3 of the test strategy outlined above. With that we now have the geronimo-deployment-plugin in maven 2. What are items 1 and 3? Don't see an outline. -David I have now begun working on item 2 which is to create a separate itests sub-project that will act as a catchment of the itests from the various modules. Now this is what we should look into - have the itests subproject as a dependency of the Geronimo project, and include the tests during the integration-phase of the lifecycle in G's build. Yet keep it separate, and thus be able to run the itests against any G's distribution binary separately. This would be the best of both worlds. I'll investigate the possibility of doing so. Jason, it is at this point that I have begun looking at TestNG. I have some questions for you. - Have you used it yourself ? - How do you think it will fit into the picture I painted above where the testsuites will be contributed by folks from the the various modules ? - Do they all have to use TestNG then ? We need a framework that can perform system level tests 'coz that is what itests are at this point. Cheers Prasad On 1/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Anyone thought about using TestNG? Its xml suite def and grouping support would be nice to define these itest suites. --jason -Original Message- From: David Blevins <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 20:41:39 To:dev@geronimo.apache.org Subject: Re: Test strategy On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote: I would like to solicit the views of others too like you and get their views and opinions. Great. I poked some other people in irc to get involved as well. Here is hoping :) More input is going to make for a better community supported solution. - The tests can all be run or only a subset of suites can be run quite easily. When you say "easily" do you mean by virtue of them being separate or some other idea? When I said we could run a subset of tests "easily" when the itests are run "on" assemblies, I meant that it would be relatively easier to selectively include/exclude tests (by categories) than when compared to doing the same if the itests are embedded with their modules. I think I follow what you mean. I guess the haze is in what you mean by "embedded." As I'm not sure, I will just state in more specific terms that I have never argued for putting the actual testing source code inside any particular assembly module -- this code is big, bulky, has a lot of deps itself and some pretty specific packaging needs. I have argued for simply running thebig test suite during the lifecycle of an assembly. Not sure if that is coming across well, or if it's being assumed that since I've recommended running the integration tests on an assembly, during the integration test phase of it's lifecycle, that the test source of course must be in the assembly as well. I believe we agree on keeping the test source in modules separate and organized. - The tests will be grouped logically into suites or categories. Each individual test will fall in one of these suites. Not sure of your usage of the word "test" in this sentence. In junit terms is that TestSuite, TestCase, or individual test method. Can you clarify? I meant TestCase. For. eg, we could have a TestSuite called, "System" which will have test cases from many different modules. We could say that these form the core set of tests. If the System suite passed, we have somewhat of a stable binary with the caveat that all functions may not work. That is much clearer to me, thanks. I do like the sort of parent module name you came up with of "System" too -- it's a keeper. At this point, I will note that it is possible put a single SuperServerSystemTest.java TestSuite in the SuperServer assemblies module (for example) that adds only the tests from the many different test modules that apply to that assembly. In summary, the cons of running the itests "on" assemblies is that it goes against the m2 lifecycle. And even though integration-test is an m2 lifecycle phase, we are not exploiting it's usage but calling it explicity again. The same has to be done for the deploy phase too. You captured that quite well. It occurred to me while writing a sentence above that there is no clear distinction between "on" and "during". In all cases you are quite literally running the tests on the assembly. The better distinction is whether or not you wish to run them "during" it's lifecycle or "after" in the lifecycle of a separate module. -David
Documentation update
Hi All, I updated the Administrative Tasks article to include how to Import database pools from JBoss 4, here is the link. http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Administrative+tasks Cheers! Hernan
Re: CORBA Incubation setup procedures
On 2/8/2006 7:27 PM, Roy T. Fielding wrote: ALL incubator requests for infrastructure MUST be reflected in an appropriate status file under http://incubator.apache.org/projects/index.html before they are requested. There are no exceptions. Roy I shall do this. Regards, Alan
[jira] Commented: (GERONIMODEVTOOLS-58) After Run->Run as Server get message "Could not find a client that is able to launch the selection"
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-58?page=comments#action_12365766 ] Sachin Patel commented on GERONIMODEVTOOLS-58: -- If you pull down the source from /devtools/eclipse-plugin and simply run "maven -o getwtp" It will generate a new image for you with the correct levels of everything inside /devtools/eclipse-plugin/target/ > After Run->Run as Server get message "Could not find a client that is able to > launch the selection" > --- > > Key: GERONIMODEVTOOLS-58 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-58 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Environment: Win2K, JDK 1.4.2 or JDK 1.5.0, WTP 1.0.1 and before, latest > eclipse plugin (20060130-0958). > Reporter: Edson Richter > Priority: Critical > > Just right click on Dynamic Web project and choose Run -> Run As Server, > select Geronimo. The app is apparently deployed (not sure), Geronimo isn't > started and message "Could not find a client that is able to launch the > selection". > Expected behaviour is browser is open and application is run. -- 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
Re: CORBA Incubation setup procedures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan D. Cabrera wrote: >> >>Anyone on general@incubator.apache.org have any comments >>to make on the proposal? Even just 'yeah, looks good >>to me' ? > > CRAP. CRAP. CRAP. CRAP. > > I could have sworn that I sent this to general@incubator.apache.org as > well. Sorry, my bad! (Sorry Geir, I was wrong!) You did, at least the 'here's how the Geronimo project voted' message. No followup or call for discussion, but the first tile *was* laid. If you meant you thought you had sent something else here, I didn't see it. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+uF7ZrNPMCpn3XdAQKyywP+M4/v2NMFetZcaqiVR2vrkACd6q3AS4JJ ChjwWpR4TPxLrd3mHRhHYV/0W6eT27GsVKfc2XcaAvfb81VGX03QYmsCkINL7//m fGsxcAutiBHs1iPsP3axLPvwTXGCKVnKV27qK7IaCNZ9rJrKdKTLcd+Vu8z4jQ2k IxGUzRinWuk= =lzLT -END PGP SIGNATURE-
[jira] Closed: (GERONIMODEVTOOLS-2) Creation of new open-ejb.jar xml requires EnterpriseBeansType element
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-2?page=all ] Sachin Patel closed GERONIMODEVTOOLS-2: --- Fix Version: (was: 1.0) Resolution: Fixed > Creation of new open-ejb.jar xml requires EnterpriseBeansType element > - > > Key: GERONIMODEVTOOLS-2 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-2 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Reporter: Sachin Patel > Assignee: Sachin Patel > Attachments: patch.txt, patch.txt > > org.apache.xmlbeans.XmlException: Invalid deployment descriptor: > [jar:file:/C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/deployer54468.tmpdir/Vdd61645.tmp!/META-INF/openejb-jar.xml:0: > error: cvc-complex-type.2.4c: Expected element '[EMAIL > PROTECTED]://www.openejb.org/xml/ns/openejb-jar' before the end of the > content in element [EMAIL PROTECTED]://www.openejb.org/xml/ns/openejb-jar] -- 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
Re: Compilation errors in module javamail-transport
On Feb 9, 2006, at 9:43 AM, Bruce Snyder wrote: On 2/9/06, Kevan Miller <[EMAIL PROTECTED]> wrote: On Feb 9, 2006, at 5:06 AM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/ store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) The javamail-transport module got created, I believe, from a combination and history. The SMTP transport code was not originally included with the spec code, but resided in the sandbox for a while. When it got promoted out of the sandbox, it was placed into it's own module in the Geronimo tree rather than rolled into the spec code. Probably ok if this is only used bundled with Geronimo, but makes less sense if we believe this might be used standalone. I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. I believe it's going to be a while before the spec module calms down. I'm finding more and more unimplemented/incompletely implemented features all the time. Hi Rick, I started to look at adding the javamail spec to GBuild, yesterday, before seeing this thread. Two benefits -- 1) forced me to look at how projects get added to continuum and 2) more importantly, should be much easier to make spec changes generally available. This will still require the occasional online build (or manual download) when the javamail spec changes, but is still better than the current situation. Since I'm ready to go, I'll go ahead and commit my changes and get things running. Thanks for doing this, Kevan, but shouldn't we put the entire specs project in there instead of just a single module? I'm not sure if other modules are going to be moving as much as JavaMail. Also, I'm not sure if GBuild will know to build the spec using Maven 2 or not - do you know? If not, as David Blevins advised me, we may need to just create a small shell script that calls mvn clean install, check it into the specs SVN base dir and then set up the JavaMail build as a shell script that calls the script. Hi Bruce, I was thinking of adding the entire specs project also. However, David Blevins advised against it and convinced me that it's not a wise thing to do. Let's see how I can do... ;-) The basic issue is that the specs project is composed of SNAPSHOT and non-SNAPSHOT modules. If we add the entire specs project to GBuild, we'll start publishing both types of modules (or it will be hard not to do so...). This seems unwise. Plus, if we update a spec without updating the spec version in pom.xml, we might start publishing non- SNAPSHOT modules with new content. Doubly unwise. I think it's best that we only add individual SNAPSHOT spec modules to GBuild. When these modules are released, we'll need to remove them from GBuild. This process could use a bit more rigor, but shouldn't be too hard to manage... Thoughts? FYI, after 1 misstep, javamail is building on GBuild. Now, just need to add specs to the rsync that's moving things to apache... --kevan
Re: Test strategy
I have completed items 1 and 3 of the test strategy outlined above. With that we now have the geronimo-deployment-plugin in maven 2. I have now begun working on item 2 which is to create a separate itests sub-project that will act as a catchment of the itests from the various modules. Now this is what we should look into - have the itests subproject as a dependency of the Geronimo project, and include the tests during the integration-phase of the lifecycle in G's build. Yet keep it separate, and thus be able to run the itests against any G's distribution binary separately. This would be the best of both worlds. I'll investigate the possibility of doing so. Jason, it is at this point that I have begun looking at TestNG. I have some questions for you. - Have you used it yourself ? - How do you think it will fit into the picture I painted above where the testsuites will be contributed by folks from the the various modules ? - Do they all have to use TestNG then ? We need a framework that can perform system level tests 'coz that is what itests are at this point. Cheers Prasad On 1/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > Anyone thought about using TestNG? > > Its xml suite def and grouping support would be nice to define these itest > suites. > > --jason > > > -Original Message- > From: David Blevins <[EMAIL PROTECTED]> > Date: Mon, 30 Jan 2006 20:41:39 > To:dev@geronimo.apache.org > Subject: Re: Test strategy > > > On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote: > > I would like to solicit the views of others too like you and get their > > views and opinions. > > Great. I poked some other people in irc to get involved as well. > Here is hoping :) More input is going to make for a better > community supported solution. > > >>> - The tests can all be run or only a subset of suites can be run > >>> quite easily. > > > >> When you say "easily" do you mean by virtue of them being separate or > >> some other idea? > > > > When I said we could run a subset of tests "easily" when the itests > > are run "on" assemblies, I meant that it would be relatively easier to > > selectively include/exclude tests (by categories) than when compared > > to doing the same if the itests are embedded with their modules. > > I think I follow what you mean. I guess the haze is in what you mean > by "embedded." > > As I'm not sure, I will just state in more specific terms that I have > never argued for putting the actual testing source code inside any > particular assembly module -- this code is big, bulky, has a lot of > deps itself and some pretty specific packaging needs. I have argued > for simply running thebig test suite during the lifecycle of an > assembly. > > Not sure if that is coming across well, or if it's being assumed that > since I've recommended running the integration tests on an assembly, > during the integration test phase of it's lifecycle, that the test > source of course must be in the assembly as well. I believe we agree > on keeping the test source in modules separate and organized. > > >>> - The tests will be grouped logically into suites or categories. > >>> Each > >>> individual test will fall in one of these suites. > > > >> Not sure of your usage of the word "test" in this sentence. In junit > >> terms is that TestSuite, TestCase, or individual test method. Can > >> you clarify? > > > > I meant TestCase. For. eg, we could have a TestSuite called, "System" > > which will have test cases from many different modules. We could say > > that these form the core set of tests. If the System suite passed, we > > have somewhat of a stable binary with the caveat that all functions > > may not work. > > That is much clearer to me, thanks. I do like the sort of parent > module name you came up with of "System" too -- it's a keeper. > > At this point, I will note that it is possible put a single > SuperServerSystemTest.java TestSuite in the SuperServer assemblies > module (for example) that adds only the tests from the many different > test modules that apply to that assembly. > > > In summary, the cons of running the itests "on" assemblies is that it > > goes against the m2 lifecycle. And even though integration-test is an > > m2 lifecycle phase, we are not exploiting it's usage but calling it > > explicity again. The same has to be done for the deploy phase too. > > You captured that quite well. > > It occurred to me while writing a sentence above that there is no > clear distinction between "on" and "during". In all cases you are > quite literally running the tests on the assembly. The better > distinction is whether or not you wish to run them "during" it's > lifecycle or "after" in the lifecycle of a separate module. > > -David >
[jira] Commented: (GERONIMODEVTOOLS-58) After Run->Run as Server get message "Could not find a client that is able to launch the selection"
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-58?page=comments#action_12365749 ] Edson Richter commented on GERONIMODEVTOOLS-58: --- As I'm using a 3.1 Eclipse with WTP 0.7 upgraded to Eclipse 3.11 then upgraded to WTP 1.0 then upgraded to every release of WTP after 1.0 (except I releases, that are 1.5 - so I didn't install none of them), I think this could be cause of the problems (some old JAR somewhere). So, this nigth I'll install clean Eclipse 3.11+WTP 1.0.1+required libs+latest Eclipse plugin+Geronimo 1.0 final binary+jetty. After that, I will have a step-by-step to reproduce (or not) the problem. If the problem could not be reproduced at clean install, I'll close this bug. Thanks, Richter > After Run->Run as Server get message "Could not find a client that is able to > launch the selection" > --- > > Key: GERONIMODEVTOOLS-58 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-58 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Environment: Win2K, JDK 1.4.2 or JDK 1.5.0, WTP 1.0.1 and before, latest > eclipse plugin (20060130-0958). > Reporter: Edson Richter > Priority: Critical > > Just right click on Dynamic Web project and choose Run -> Run As Server, > select Geronimo. The app is apparently deployed (not sure), Geronimo isn't > started and message "Could not find a client that is able to launch the > selection". > Expected behaviour is browser is open and application is run. -- 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
Geronimo Web site update
Hi All, I created a JIRA with the new Web site based on the template from EPIQ. So far, although I mainly focused on the template I also edited some of the content. I have not modified the build method so it still uses ant/anakia. Please send your comments and suggestions. https://issues.apache.org/jira/browse/GERONIMO-1611 Cheers! Hernan
[jira] Updated: (GERONIMO-1611) Apache Geronimo Web site update
[ http://issues.apache.org/jira/browse/GERONIMO-1611?page=all ] Hernan Cunico updated GERONIMO-1611: Attachment: sites_geronimo.06-02-09.zip sites_geronimo.06-02-09.zip has more updates to the content and includes a site.diff > Apache Geronimo Web site update > --- > > Key: GERONIMO-1611 > URL: http://issues.apache.org/jira/browse/GERONIMO-1611 > Project: Geronimo > Type: Improvement > Components: website > Reporter: Hernan Cunico > Assignee: Bruce Snyder > Attachments: sites_geronimo.06-02-08.zip, sites_geronimo.06-02-09.zip > > I have updated the template of the current Apache Geronimo Web site to use > the one proposed from EPIQ -- 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
[jira] Commented: (GERONIMODEVTOOLS-58) After Run->Run as Server get message "Could not find a client that is able to launch the selection"
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-58?page=comments#action_12365742 ] Sachin Patel commented on GERONIMODEVTOOLS-58: -- I'm still unable to reproduce this. > After Run->Run as Server get message "Could not find a client that is able to > launch the selection" > --- > > Key: GERONIMODEVTOOLS-58 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-58 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Environment: Win2K, JDK 1.4.2 or JDK 1.5.0, WTP 1.0.1 and before, latest > eclipse plugin (20060130-0958). > Reporter: Edson Richter > Priority: Critical > > Just right click on Dynamic Web project and choose Run -> Run As Server, > select Geronimo. The app is apparently deployed (not sure), Geronimo isn't > started and message "Could not find a client that is able to launch the > selection". > Expected behaviour is browser is open and application is run. -- 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
Re: Compilation errors in module javamail-transport
On 2/9/06, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
> On Feb 9, 2006, at 5:06 AM, Rick McGuire wrote:
>
> > David Blevins wrote:
> >> On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote:
> >>
> >>> David Blevins wrote:
>
> On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote:
>
> > David Blevins wrote:
> >> At first blush it looks like there are just three util classes
> >> that make the javamail-transport module dependent on our
> >> specific javamail implementation.
> >>
> Do you think it makes much sense to try and keep them separate?
> Or are they too coupled already to be worth it?
>
> It's kind of a PITA to have to have a tight (i.e. snapshot)
> dependency on a spec project. But obviously javamail is a mess
> and it may just be too hard.
> >>> I'm starting to think it was a mistake to have javamail-transport
> >>> be a separate jar file from the spec code. In the Sun case, all
> >>> of the code is in a single jar, so you only need the javamail jar
> >>> and the activation jar to use it. Because of our current split,
> >>> we require 3 jars. It might make sense to move the transport/
> >>> store code into the spec jar since they are so tightly coupled.
> >>
> >> If they are fundamentally one unit and completely tied together,
> >> it may make more sense to put them together. Course, I may not
> >> understand the implications of what I say :)
> > The javamail-transport module got created, I believe, from a
> > combination and history. The SMTP transport code was not
> > originally included with the spec code, but resided in the sandbox
> > for a while. When it got promoted out of the sandbox, it was
> > placed into it's own module in the Geronimo tree rather than rolled
> > into the spec code. Probably ok if this is only used bundled with
> > Geronimo, but makes less sense if we believe this might be used
> > standalone.
> >
> >>
> >> I guess if the javamail-transport module is going to be where all
> >> the change occurs, then having it outside specs kind of handy --
> >> provided the javamail module itself calms down and doesn't keep
> >> changing right along with it.
> > I believe it's going to be a while before the spec module calms
> > down. I'm finding more and more unimplemented/incompletely
> > implemented features all the time.
>
> Hi Rick,
> I started to look at adding the javamail spec to GBuild, yesterday,
> before seeing this thread. Two benefits -- 1) forced me to look at
> how projects get added to continuum and 2) more importantly, should
> be much easier to make spec changes generally available.
>
> This will still require the occasional online build (or manual
> download) when the javamail spec changes, but is still better than
> the current situation.
>
> Since I'm ready to go, I'll go ahead and commit my changes and get
> things running.
Thanks for doing this, Kevan, but shouldn't we put the entire specs
project in there instead of just a single module? I'm not sure if
other modules are going to be moving as much as JavaMail.
Also, I'm not sure if GBuild will know to build the spec using Maven 2
or not - do you know? If not, as David Blevins advised me, we may need
to just create a small shell script that calls mvn clean install,
check it into the specs SVN base dir and then set up the JavaMail
build as a shell script that calls the script.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
[jira] Updated: (GERONIMO-1531) KeyStore portlet should support deletion of certificates and private keys
[ http://issues.apache.org/jira/browse/GERONIMO-1531?page=all ] Vamsavardhana Reddy updated GERONIMO-1531: -- Geronimo Info: [Patch Available] Fix Version: 1.0.1 > KeyStore portlet should support deletion of certificates and private keys > - > > Key: GERONIMO-1531 > URL: http://issues.apache.org/jira/browse/GERONIMO-1531 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0 > Reporter: Vamsavardhana Reddy > Priority: Minor > Fix For: 1.x, 1.1, 1.0.1 > Attachments: GERONIMO-1531.patch > > KeyStore portlet currently supports generation of keypairs, adding trusted > certificates to keystore and importing certificate issued by CA. It does not > address "deletion" of any of these from the keystore. -- 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
[jira] Updated: (GERONIMO-1531) KeyStore portlet should support deletion of certificates and private keys
[ http://issues.apache.org/jira/browse/GERONIMO-1531?page=all ] Vamsavardhana Reddy updated GERONIMO-1531: -- Attachment: GERONIMO-1531.patch GERONIMO-1531.patch: Provides delete functionality for private keys and trusted certificates. > KeyStore portlet should support deletion of certificates and private keys > - > > Key: GERONIMO-1531 > URL: http://issues.apache.org/jira/browse/GERONIMO-1531 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0 > Reporter: Vamsavardhana Reddy > Priority: Minor > Fix For: 1.x, 1.1, 1.0.1 > Attachments: GERONIMO-1531.patch > > KeyStore portlet currently supports generation of keypairs, adding trusted > certificates to keystore and importing certificate issued by CA. It does not > address "deletion" of any of these from the keystore. -- 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
Re: NPE in HOWLLog in boot
Gianny -- it looks like you fixed trunk. Is this a problem in the 1.0 branch as well? If so, could you fix it there too? Thanks, Aaron On 2/9/06, Gianny Damour <[EMAIL PROTECTED]> wrote: > Hi Jason, > > This has now been fixed. XidFactory is now being properly injected and G > should start fine. > > Thanks, > Gianny > > Jason Dillon wrote: > > >I'm not sure how I got G into this state, but its barfing on boot with: > > > > > >Booting Geronimo Kernel (in Java 1.4.2_09)... > >Started configuration 1/16 0s geronimo/rmi-naming/1.0/car > >18:57:25,971 ERROR [GBeanInstanceState] Error while starting; GBean is > >now in the FAILED state: > >objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionLog,name=HOWLTransactionLog" > >java.lang.NullPointerException > >at > > org.apache.geronimo.transaction.log.HOWLLog$GeronimoReplayListener.onRecord(HOWLLog.java:362) > >at > > org.objectweb.howl.log.xa.XALogger.replayActiveTx(XALogger.java:1059) > >at > > org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:220) > >at > > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) > >at > > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > >at > > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > >at > > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > >at > > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > >at > > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > >at > > org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) > >at > > org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke() > >at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > >at > > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > >at > > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > >at > > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) > >at > > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) > >at > > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) > >at > > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142) > >at > > org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke() > >at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > >at > > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > >at > > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) > >at > > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > >at > > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > >at > > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > >at > > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > >at > > org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$ac1e62eb.start() > >at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:323) > >at org.apache.geronimo.system.main.Daemon.(Daemon.java:82) > >at org.apache.geronimo.system.main.Daemon.main(Daemon.java:404) > >... > > > > > >Most GBeans do not start successfully after that... G is hosed at this > >point, had to nuke the txlogs to get a usage G again. > > > >That line is: > > > > > >Xid masterXid = xidFactory.recover(formatId, globalId, branchId); > > > > > >xidFactory not getting dependency injected? > > > >--jason > > > > > > > > > > > > >
Re: NPE in HOWLLog in boot
Hi Jason, This has now been fixed. XidFactory is now being properly injected and G should start fine. Thanks, Gianny Jason Dillon wrote: I'm not sure how I got G into this state, but its barfing on boot with: Booting Geronimo Kernel (in Java 1.4.2_09)... Started configuration 1/16 0s geronimo/rmi-naming/1.0/car 18:57:25,971 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionLog,name=HOWLTransactionLog" java.lang.NullPointerException at org.apache.geronimo.transaction.log.HOWLLog$GeronimoReplayListener.onRecord(HOWLLog.java:362) at org.objectweb.howl.log.xa.XALogger.replayActiveTx(XALogger.java:1059) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:220) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) at org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) at org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$ac1e62eb.start() at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:323) at org.apache.geronimo.system.main.Daemon.(Daemon.java:82) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:404) ... Most GBeans do not start successfully after that... G is hosed at this point, had to nuke the txlogs to get a usage G again. That line is: Xid masterXid = xidFactory.recover(formatId, globalId, branchId); xidFactory not getting dependency injected? --jason
[jira] Commented: (GERONIMO-1599) HOWLLog throws NPE because XidFactory is missing
[
http://issues.apache.org/jira/browse/GERONIMO-1599?page=comments#action_12365730
]
Gianny Damour commented on GERONIMO-1599:
-
Put in an additional fix: XidFactory is now defined as a GBean in the
j2ee-server and client configurations and passed to HOWLTransactionLog and
TransactionManager. The tmId is set to 71,84,77,73,68, i.e. "GTMID".
> HOWLLog throws NPE because XidFactory is missing
>
>
> Key: GERONIMO-1599
> URL: http://issues.apache.org/jira/browse/GERONIMO-1599
> Project: Geronimo
> Type: Bug
> Components: transaction manager
> Versions: 1.0
> Reporter: Jason Dillon
> Assignee: David Jencks
> Priority: Critical
> Fix For: 1.0.1, 1.1
>
> I've run into a situation where an EJB transaction hangs, and when I kill G
> and reboot, it fails with this NPE:
> {noformat}
> Booting Geronimo Kernel (in Java 1.4.2_09)...
> Started configuration 1/23 0s geronimo/rmi-naming/1.0/car
> 16:15:06,779 ERROR [GBeanInstanceState] Error while starting; GBean is
> now in the FAILED state:
> objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionLog,name=HOWLTransactionLog"
> java.lang.NullPointerException
>at
> org.apache.geronimo.transaction.log.HOWLLog$GeronimoReplayListener.onRecord(HOWLLog.java:362)
>at
> org.objectweb.howl.log.xa.XALogger.replayActiveTx(XALogger.java:1059)
>at
> org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:220)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
>at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
>at
> org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315)
>at
> org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
>at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
>at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173)
>at
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142)
>at
> org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke()
>at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
>at
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
>at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>at
> org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$ac1e62eb.start()
>at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:323)
>at org.apache.geronimo.system.main.Daemon.(Daemon.java:82)
>at org.apache.geronimo.system.main.Daemon.main(Daemon.java:404)
> Started configuration 2/23 1s geronimo/j2ee-server/1.0/car
> {noformat}
> The system is useless at this point, need to rm var/txlog/* to get a
> functional G back.
> For some reason the XidFactory that is passed in to the HOWLLog is null.
--
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
Re: Compilation errors in module javamail-transport
On Feb 9, 2006, at 5:06 AM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/ store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) The javamail-transport module got created, I believe, from a combination and history. The SMTP transport code was not originally included with the spec code, but resided in the sandbox for a while. When it got promoted out of the sandbox, it was placed into it's own module in the Geronimo tree rather than rolled into the spec code. Probably ok if this is only used bundled with Geronimo, but makes less sense if we believe this might be used standalone. I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. I believe it's going to be a while before the spec module calms down. I'm finding more and more unimplemented/incompletely implemented features all the time. Hi Rick, I started to look at adding the javamail spec to GBuild, yesterday, before seeing this thread. Two benefits -- 1) forced me to look at how projects get added to continuum and 2) more importantly, should be much easier to make spec changes generally available. This will still require the occasional online build (or manual download) when the javamail spec changes, but is still better than the current situation. Since I'm ready to go, I'll go ahead and commit my changes and get things running. --kevan Could go a couple ways. -David
Re: Spring support in Geronimo
Maybe I 'm still miss some point, but I think that's what do the
org.apache.geronimo.transaction.context.GeronimoTransactionManager
[1] of the jencks project. I was in need for it in ServiceMix, because
when using xa transactions, the JBI container has to suspend / resume
transactions.
This is due to the fact the JBI components pull messages from a queue in
their own threads, but the transaction is conveyed on the JBI
message exchange. Therefore, ServiceMix suspends the current transaction
when the message is queued, and resume it when it is dequeued
(in another thread).
The problem is that the only standard way to suspend / resume
transactions is to use the TransactionManager, but
the geronimo implementation does not work well when working on
UserTransaction : all resources enlisted in the user transaction are
managed by the TransactionContextManager and if you call the
TransactionManager directly, the TransactionContextManager is bypassed.
The GeronimoTransactionManager (in jencks project) wraps the
TransactionContextManager and implements both UserTransaction and
TransactionManager. In addition, it allows the use of unmanaged threads
by creating an empty context for the thread where the transaction
is started / resumed, if none exists already. This implementation can
easily be used by the existing spring JtaTransactionManager.
The gbeans written for ServiceMix do use this implementation.
Cheers,
Guillaume Nodet
[1]
http://cvs.codehaus.org/viewrep/jencks/jencks/src/main/java/org/apache/geronimo/transaction/context
David Jencks wrote:
This looks like it should work. I think there is some chance that it
would work even better if we provided a transaction manager that
wraps our transactioncontextmanager, but it's too early in the
morning for me to think straight about it. If you get into problem
with connections not being returned to the pool let me know and I
will think about it harder. How do you provide access to the jdbc
connection? By declaring a resource-ref in the j2ee component that
is calling hibernate, or some other way?
thanks
david jencks
On Feb 3, 2006, at 12:42 AM, Jason Dillon wrote:
It looks like you can be the first to test out my new
SpringTransactionManager :-). It wraps our
TransactionContextManager in a PlatformTransactionManager
subclass. You need to give it 2 constructor args, the kernel name
and the tcm object name. The normal values are in the comments in
the class.
Aight... kick it down yo.
What does Hibernate need? Can it work off a spring tm or does it
need something else?
I think it wants a special lookup class... I wrote one up tonight
based on comments to the dev list a while ago... creating a proxy to
the TransactionManager instance. I have yet to test it though.
If you can come up with some kind of spring app that ought to work
and uses the spring tm I would be able to test and perhaps debug my
code :-)
I might be able to come up with something simple... though right now
first priority is to just get something... anything working inside
of Geronimo so our SE dept. can test it.
Anyways, looks like spring needs a Geronimo version like:
http://www.springframework.org/docs/api/org/springframework/
transaction/jta/WebSphereTransactionManagerFactoryBean.html
I've yet to look at what this puppy does.
And Hibernate needs a Geronimo version of:
http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/
hibernate/transaction/JOTMTransactionManagerLookup.java?
rev=1.1&view=auto
This is what I wrote and will be testing out tomorrow.
package com.solidusnetworks.utils.geronimo;
import java.util.Properties;
import javax.transaction.TransactionManager;
import javax.management.ObjectName;
import net.sf.hibernate.HibernateException;
import net.sf.hibernate.transaction.TransactionManagerLookup;
import org.apache.geronimo.kernel.Kernel;
import org.apache.geronimo.kernel.KernelRegistry;
/**
* Provides lookup of the Geronimo (1.0) transaction manager.
*
* @version $Id$ $Date$
* @author mailto:[EMAIL PROTECTED]">Jason Dillon
*/
public class GeronimoTransactionManagerLookup
implements TransactionManagerLookup
{
public static final String TXM_GBEAN_NAME =
"geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-
server/1.0/
car,J2EEServer=geronimo,j2eeType=TransactionManager,name=TransactionMa
nager";
public static final String USER_TXN_NAME = "java:comp/
UserTransaction";
public TransactionManager getTransactionManager(final Properties
props) throws HibernateException {
try {
//
// FIXME: This is probably not work when Geronimo
versions change... :-(
//
ObjectName TM_NAME = new ObjectName(TXM_GBEAN_NAME);
Kernel kernel = KernelRegistry.getSingleKernel();
return (TransactionManager) kernel.getProxyManager
().createProxy(TM_NAME, TransactionManager.class);
}
Re: Oracle XA RAR for G1.0?
On Thu, 9 Feb 2006, Jason Dillon wrote: > Thanks! My DBA cleared this for me and now XA is working with 1 Oracle > DS and 1 ActiveMQ CF. I still can not get the 2 Oracle datasources > working together with XA though. Glad it worked out. > Did anyone have a chance to peek at that URL I mailed describing a > similar problem? The one that suggested that some Oracle XA flag needs > to be set for loosly coupled branches? I haven't looked at it.
Re: Compilation errors in module javamail-transport
David Blevins wrote: On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) The javamail-transport module got created, I believe, from a combination and history. The SMTP transport code was not originally included with the spec code, but resided in the sandbox for a while. When it got promoted out of the sandbox, it was placed into it's own module in the Geronimo tree rather than rolled into the spec code. Probably ok if this is only used bundled with Geronimo, but makes less sense if we believe this might be used standalone. I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. I believe it's going to be a while before the spec module calms down. I'm finding more and more unimplemented/incompletely implemented features all the time. Could go a couple ways. -David
[jira] Closed: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=all ] Jeff Genender closed GERONIMO-1480: --- Resolution: Fixed Per Jian, this is now fixed. > Cross context include does not set jacc contextID for 2nd web app. (Tomcat > only) > > > Key: GERONIMO-1480 > URL: http://issues.apache.org/jira/browse/GERONIMO-1480 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0.1, 1.1 > Reporter: David Jencks > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1, 1.0.1 > > If you do a cross context include from web app A to web app B, the jacc > contextID fetched from PolicyContext when you evaluate isUserInRole in web > app B is the contextID for A, not B. > Presumably the cross context dispatch does not go through the > PolicyContextValve for B. Here's a thread trace that demonstrates this, with > a couple annotations. > [EMAIL PROTECTED] daemon prio=5, in group "main", status: RUNNING > implies():80, GeronimoPolicy.java > implies():46, JaasPolicyCoordinator.java > implies():189, ProtectionDomain.java > checkPermission():254, AccessControlContext.java > hasRole():248, TomcatGeronimoRealm.java > isUserInRole():2128, Request.java > isUserInRole():761, RequestFacade.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():265, PortletRequestImpl.java > _jspService():46, roles.jsp > service():97, HttpJspBase.java > service():688, HttpServlet.java > service():322, JspServletWrapper.java > serviceJspFile():314, JspServlet.java > service():264, JspServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > include():72, JetspeedRequestDispatcher.java > doView():363, GenericServletPortlet.java > doDispatch():250, GenericPortlet.java > render():178, GenericPortlet.java > render():102, JetspeedPortletInstance.java > THIS IS WEB APP B > doGet():230, JetspeedContainerServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > THIS IS A INCLUDING B > invoke():213, ServletPortletInvoker.java > render():125, ServletPortletInvoker.java > renderPortlet():119, PortletContainerImpl.java > renderPortlet():120, JetspeedPortletContainerWrapper.java > execute():120, RenderingJobImpl.java > renderNow():110, PortletRendererImpl.java > aggregateAndRender():199, PageAggregatorImpl.java > aggregateAndRender():182, PageAggregatorImpl.java > build():106, PageAggregatorImpl.java > invoke():48, AggregatorValve.java > invokeNext():166, JetspeedPipeline.java > invoke():132, ActionValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():76, ContainerValve.java > invokeNext():166, JetspeedPipeline.java > invoke():100, DecorationValve.java > invokeNext():166, JetspeedPipeline.java > invoke():179, ProfilerValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():143, LoginValidationValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():148, PasswordCredentialValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():168, LocalizationValveImpl.java > invokeNext():166, JetspeedPipeline.java > run():117, AbstractSecurityValve.java > doPrivileged():-1, AccessController.java > doAsPrivileged():437, Subject.java > invoke():111, AbstractSecurityValve.java > invokeNext():166, JetspeedPipeline.java > invoke():55, PortalURLValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():128, CapabilityValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():145, JetspeedPipeline.java > service():231, JetspeedEngine.java > THIS IS WEB APP A: > doGet():226, JetspeedServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > in
[jira] Commented: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=comments#action_12365703 ] Jian Liao commented on GERONIMO-1480: - Your new patch is like what I am done on my testing env, but I use "mb.setString(webContext.getPath() + dispatchPath);". because mapper initialize its internal context with the value return by webContext.getPath() in org.apache.catalina.core.StandardContext, line 4110 (Tomcat 5.5.12). But they are exactly the same cause getPath() will delegate to getName() :-). Now both policy context and jndi context work well !!! Thanks, jeff. - Jian Liao > Cross context include does not set jacc contextID for 2nd web app. (Tomcat > only) > > > Key: GERONIMO-1480 > URL: http://issues.apache.org/jira/browse/GERONIMO-1480 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0.1, 1.1 > Reporter: David Jencks > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1, 1.0.1 > > If you do a cross context include from web app A to web app B, the jacc > contextID fetched from PolicyContext when you evaluate isUserInRole in web > app B is the contextID for A, not B. > Presumably the cross context dispatch does not go through the > PolicyContextValve for B. Here's a thread trace that demonstrates this, with > a couple annotations. > [EMAIL PROTECTED] daemon prio=5, in group "main", status: RUNNING > implies():80, GeronimoPolicy.java > implies():46, JaasPolicyCoordinator.java > implies():189, ProtectionDomain.java > checkPermission():254, AccessControlContext.java > hasRole():248, TomcatGeronimoRealm.java > isUserInRole():2128, Request.java > isUserInRole():761, RequestFacade.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():265, PortletRequestImpl.java > _jspService():46, roles.jsp > service():97, HttpJspBase.java > service():688, HttpServlet.java > service():322, JspServletWrapper.java > serviceJspFile():314, JspServlet.java > service():264, JspServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > include():72, JetspeedRequestDispatcher.java > doView():363, GenericServletPortlet.java > doDispatch():250, GenericPortlet.java > render():178, GenericPortlet.java > render():102, JetspeedPortletInstance.java > THIS IS WEB APP B > doGet():230, JetspeedContainerServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > THIS IS A INCLUDING B > invoke():213, ServletPortletInvoker.java > render():125, ServletPortletInvoker.java > renderPortlet():119, PortletContainerImpl.java > renderPortlet():120, JetspeedPortletContainerWrapper.java > execute():120, RenderingJobImpl.java > renderNow():110, PortletRendererImpl.java > aggregateAndRender():199, PageAggregatorImpl.java > aggregateAndRender():182, PageAggregatorImpl.java > build():106, PageAggregatorImpl.java > invoke():48, AggregatorValve.java > invokeNext():166, JetspeedPipeline.java > invoke():132, ActionValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():76, ContainerValve.java > invokeNext():166, JetspeedPipeline.java > invoke():100, DecorationValve.java > invokeNext():166, JetspeedPipeline.java > invoke():179, ProfilerValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():143, LoginValidationValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():148, PasswordCredentialValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():168, LocalizationValveImpl.java > invokeNext():166, JetspeedPipeline.java > run():117, AbstractSecurityValve.java > doPrivileged():-1, AccessController.java > doAsPrivileged():437, Subject.java > invoke():111, AbstractSecurityValve.java > invokeNext():166, JetspeedPipeline.java > invoke():55, Por
Re: CORBA Incubation setup procedures
(infra@ dropped from CC on purpose) On Wed, Feb 08, 2006 at 08:41:26PM -0500, Rodent of Unusual Size wrote: > Alan D. Cabrera wrote: > > I think I need: > > > > * SVN > > o http://svn.apache.org/repos/asf/incubator/yoko > > * Jira > > * Mailing lists > > o [EMAIL PROTECTED] > > o [EMAIL PROTECTED] > > o [EMAIL PROTECTED] > > Hang on a moment. I see that Geronimo is cool with it, > but I don't see any discussion of this proposal on > [EMAIL PROTECTED] just the message saying > that Geronimo wants to sponsor it. > > Before we start setting things up, I'd really like to > call for some opinions about the proposal from *outside* > the sponsoring TLP. > > Alan's message points out that the proposal is at > http://wiki.apache.org/incubator/CorbaProposal > > Anyone on general@incubator.apache.org have any comments > to make on the proposal? Even just 'yeah, looks good > to me' ? No way. *shrug*. > Mine is that 22 seems a rather large number (!) of initial > committers for a podling.. And the amount of publicly archived discussion about it or what the is precisely going on or anything like that is also shockingly missing. > If nothing further comes from this message within a couple > of days, let's go ahead. Personally and as an ASF member, I think its not a good idea to have a CORBA implementation under the wings of the geronimo project (Re: "umbrella projects bad" threads from long ago). As an incubator PMC member, I don't think the incubator should be telling the geronimo project that they shouldn't have a CORBA implementation. As I see it, that's a responsibility for the geronimo PMC (which obviously seems to disagree), its chair (eg, you), the ASF board, and ultimately the membership. I think both you and the ASF board are well aware of what is going on within the geronimo project and I trust that things will work out one way or another in the end. Secondly, as an incubator PMC member, I think the geronimo project is not fulfilling its part of the incubation process and not communicating enough at all and its making me very grumpy. I wrote a rather generic message tot [EMAIL PROTECTED] and [EMAIL PROTECTED] about this stuff recently. This is just another example. The only further action I'll be taking with regard to this mess is ignoring it until it goes away. - LSD
[jira] Commented: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=comments#action_12365699 ] Jeff Genender commented on GERONIMO-1480: - Thank Jian. Fixed this issue now too. So please try again from HEAD. Thanks for bearing with me on this...I don't have Jetspeed to test this, so I have been doing it with unit tests ;-) Lets hope this one finally does it. > Cross context include does not set jacc contextID for 2nd web app. (Tomcat > only) > > > Key: GERONIMO-1480 > URL: http://issues.apache.org/jira/browse/GERONIMO-1480 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0.1, 1.1 > Reporter: David Jencks > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1, 1.0.1 > > If you do a cross context include from web app A to web app B, the jacc > contextID fetched from PolicyContext when you evaluate isUserInRole in web > app B is the contextID for A, not B. > Presumably the cross context dispatch does not go through the > PolicyContextValve for B. Here's a thread trace that demonstrates this, with > a couple annotations. > [EMAIL PROTECTED] daemon prio=5, in group "main", status: RUNNING > implies():80, GeronimoPolicy.java > implies():46, JaasPolicyCoordinator.java > implies():189, ProtectionDomain.java > checkPermission():254, AccessControlContext.java > hasRole():248, TomcatGeronimoRealm.java > isUserInRole():2128, Request.java > isUserInRole():761, RequestFacade.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():265, PortletRequestImpl.java > _jspService():46, roles.jsp > service():97, HttpJspBase.java > service():688, HttpServlet.java > service():322, JspServletWrapper.java > serviceJspFile():314, JspServlet.java > service():264, JspServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > include():72, JetspeedRequestDispatcher.java > doView():363, GenericServletPortlet.java > doDispatch():250, GenericPortlet.java > render():178, GenericPortlet.java > render():102, JetspeedPortletInstance.java > THIS IS WEB APP B > doGet():230, JetspeedContainerServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > THIS IS A INCLUDING B > invoke():213, ServletPortletInvoker.java > render():125, ServletPortletInvoker.java > renderPortlet():119, PortletContainerImpl.java > renderPortlet():120, JetspeedPortletContainerWrapper.java > execute():120, RenderingJobImpl.java > renderNow():110, PortletRendererImpl.java > aggregateAndRender():199, PageAggregatorImpl.java > aggregateAndRender():182, PageAggregatorImpl.java > build():106, PageAggregatorImpl.java > invoke():48, AggregatorValve.java > invokeNext():166, JetspeedPipeline.java > invoke():132, ActionValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():76, ContainerValve.java > invokeNext():166, JetspeedPipeline.java > invoke():100, DecorationValve.java > invokeNext():166, JetspeedPipeline.java > invoke():179, ProfilerValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():143, LoginValidationValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():148, PasswordCredentialValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():168, LocalizationValveImpl.java > invokeNext():166, JetspeedPipeline.java > run():117, AbstractSecurityValve.java > doPrivileged():-1, AccessController.java > doAsPrivileged():437, Subject.java > invoke():111, AbstractSecurityValve.java > invokeNext():166, JetspeedPipeline.java > invoke():55, PortalURLValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():128, CapabilityValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():145, JetspeedPipeline.java
Re: Maven 2 Repository for Geronimo
At the very least, I'd like the interface to be the same. So far I have not found any reason to believe that use of the org.apache.geronimo.kernel.repository.* interfaces will be a problem. We just write a facade that impls our repo interfaces and then delegates to the Maven2 API. Except for WriteableRepository that is... not sure how that relates directly. It should be possible, but since Maven2 could really bet a set of repositories it is unclear how to properly implement this interface. Could be that writable methods always operate on the local repository cache. Can you find and post the maven2 repository interface to this list? As soon as I figure out which interfaces are relevant. There is no single interface, but stuff from org.apache.maven.artifact.* My feeling on this is if it works it works. I don't think we should turn on downloading by default anytime soon, but I think we should make it available as an options so people can begin to play with it. I don't think it should ever be on by default. But if it works, it would be nice to see a configuration portlet to allow repositories to be setup and then enabled/disabled. Then we could ship with a remote repository configured, but diabled (so no remote, unless someone enables it). Anyways, too soon for that... first thing is to get it working. I have to work on some of this XA Oracle stuff first, but after that I will get an example put together and publish it to the group. --jason
