[jira] Created: (SM-348) Unable to send SOAP 1.1 messages
Unable to send SOAP 1.1 messages Key: SM-348 URL: http://jira.activemq.org/jira//browse/SM-348 Project: ServiceMix Type: Bug Components: servicemix-soap, servicemix-http Reporter: Guillaume Nodet Assigned to: Guillaume Nodet Fix For: 3.0-M1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: exposing a jbi endpoint as a SOAP endpoint
I did as you said and it worked, thanks.
There are still a couple of issue that I'd like to understand:
1. the SOAP-Http proxy service doesn't provide a wsdl. Do you think that
could be possible to take the wsdl of the proxied service strip the jbi
binding and put a SOAP-http binding?
2. I configured the routing using the xbean file:
http:endpoint service=im:VinciService
endpoint=imhttp:VinciService
role=consumer
locationURI=http://localhost:8192/Service/VinciService;
defaultMep=http://www.w3.org/2004/08/wsdl/in-out;
soap=true /
I'd like to do the same using the standard connection definitions of the
jbi deployment descriptor of the service assembly. Does it make sense
and is it supported in serivicemix?
connection
consumer endpoint-name=im:VinciServiceHttpPort
service-name=im:VinciService
/consumer
provider endpoint-name=im:VinciServiceJBIPort
service-name=im:VinciService
/provider
/connection
If I try to do it servicemix complains that it can't find the cosumer
service (the proxy), I believe it does is because the proxy service
doesn't register a wsdl, so back to the previous point.
About the service-common library I found it useful but not much
documented, it took me a couple of days of code reading to understand
what it could do for me.
Last thing I suggest to add to the maven-servicemix-plugin a couple of goal to
help the deploy of install zip and service assemblies.
supposing to have a directory structure that mirrors the service assembly, I
did the following scripts that could be a start:
goal name=jbi:install prereqs=jbi:jbi description=install installer in
deploy directory of esb
ant:echoinstalling installer/ant:echo
ant:delete file=${maven.jbi.esb.dir}/install/${maven.jbi.final.name}/
ant:copy file=${maven.build.dir}/${maven.jbi.final.name}
todir=${maven.jbi.esb.dir}/install /
/goal
goal name=jbi:deploy
prereqs=jbi:create-sa
description=deploy the serice assembies
ant:echodeploying sa/ant:echo
ant:delete file=${maven.jbi.esb.dir}/deploy/${jbi.assembly.name}.zip/
ant:copy file=${basedir}/target/${jbi.assembly.name}.zip
todir=${maven.jbi.esb.dir}/deploy /
/goal
goal name=jbi:create-sa description=create the service assembly
j:set var=saname value=${jbi.assembly.name} /
j:set var=keysaname value=jbi.assembly.unitname.${saname} /
util:tokenize var=sus
delim=,${context.getVariable(keysaname)}/util:tokenize
ant:mkdir dir=${basedir}/target/jbi_sa_${saname} /
j:forEach var=su items=${sus}
log:infogenerate service unit zip file for ${su}/log:info
ant:zip
destfile=${basedir}/target/jbi_sa_${saname}/${su}.zip
basedir=${jbi.assembly.dir}/${jbi.assembly.name}/${su}/
/j:forEach
ant:zip
destfile=${basedir}/target/${jbi.assembly.name}.zip
ant:zipfileset
dir=${jbi.assembly.dir}/${jbi.assembly.name}/META-INF prefix=META-INF/
ant:zipfileset dir=${basedir}/target/jbi_sa_${saname}
includes=*.zip/
/ant:zip
/goal
bye
Raffaele
On Thu, 2006-03-09 at 12:22 +0100, Guillaume Nodet wrote:
See comments inline
On 3/9/06, Raffaele Spazzoli [EMAIL PROTECTED] wrote:
I'm developing a binding component using the sericemix-common library
and taking inspiration (i.e. coping :-) )from the jsr181 component.
If you have concerns with the existing component (missing features,
bugs...),
please raise them.
It works and when I generate the wsdl for my deployed service I obtain a
jbi binding:
wsdl:binding name=VinciServiceJBIBinding
type=tns:VinciServicePortType
wsdlsoap:binding style=document
transport=http://java.sun.com/xml/ns/jbi/binding/service+engine/
wsdl:operation name=vinciOperation
wsdlsoap:operation soapAction=/
wsdl:input name=vinciOperationRequest
wsdlsoap:body use=literal/
/wsdl:input
wsdl:output name=vinciOperationResponse
wsdlsoap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=VinciService
wsdl:port binding=tns:VinciServiceJBIBinding
name=VinciServiceJBIPort
wsdlsoap:address
location=jbi://{http://vinci.test.iif.imolinfo.it}VinciService/
/wsdl:port
For what I understand (and is not much yet) of the jbi specification
this is ok and means that my component is listening on the NMR message
bus. Now I want to expose my service to external clients via SOAP
binding (lets say SOAP over HTTP).
I think this should be possible just configuring a SOAP endpoint to
route the messages it receives to my jbi endpoint. I didn't find a
standard way to do it. Is it possible and
Re: M2 migration status
As shown below two versions of the plugin are loaded! Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/pl ugins/maven-surefire-plugin/2.1.3-SNAPSHOT/maven-surefire-plugin-2.1.3-20060311. 140339-5.pom 1K downloaded Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins /maven-surefire-plugin/2.1.3-SNAPSHOT/maven-surefire-plugin-2.1.3-20060228.01294 4-10.jar 9K downloaded [INFO] [resources:resources] .. ... Downloading: http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins /maven-surefire-plugin/2.1.3-SNAPSHOT/maven-surefire-plugin-2.1.3-20060228.01294 4-10.pom 1K downloaded Another thing... A file called network.log is generated in surefire-reports dir using mvn -Dlog4j.configuration=file:m2-log4j.properties . But it is not created by the systemProperties method. This needs to be investigated too. I came across this http://jira.codehaus.org/browse/MSUREFIRE-71. We also use basedir property in ServerInfoTest.java. M2 build can not be expected to work reliably until these issues are resolved. But this should not prevent us from migrating more modules. Thanks Anita --- Jacek Laskowski [EMAIL PROTECTED] wrote: 2006/3/11, anita kulshreshtha [EMAIL PROTECTED]: I am using win XP, j2sdk-1.4.2-09 and maven 2.0.2. I can not build a module which has forkModepertest/forkMode line. After commenting it out the module builds fine. One such example is security module. A file named exported-pom.xml is created in target directory. This file seems (attached here) fine except that the plugin .maven-surefine-plugin appears twice! Is anyone else having the same problem. They all work(ed) for me. As I wrote in one of the recent comments in JIRA, make sure you're using the very latest maven-surefire-plugin. Mine is 2.1.3-20060228.012944-10. Anita Jacek -- Jacek Laskowski http://www.laskowski.org.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: ActiveMQ Graduation From Incubator
Alan D. Cabrera wrote: This is not a vote, but simply a discussion about the graduation of ActiveMQ from the Incubator. The status file is located here: https://svn.apache.org/repos/asf/incubator/activemq/trunk/STATUS We are proactively seeking feedback in the interest of graduation. Regards, Alan In regards to the infrastructure items, IMHO JIRA is a critical service required by the project and should be run on ASF infrastructure. Some of the benefits of moving ActiveMQ's JIRA data to the ASF would be: * JIRA svn integration (ability to see svn changes associated with a JIRA issue) * Backups of JIRA data under ASF control Seems like now would be a good time to do this, but currently JIRA does not have the ability to import data for a single project from data exported from another JIRA instance ( http://jira.atlassian.com/browse/JRA-1604 ). Would it be practical to follow Jeff Turner's suggestion in https://issues.apache.org/jira/browse/INFRA-713 , e.g. downloading a copy of JIRA 'Standalone' (built-in hsql db), load the data into it, delete everything not relating to ActiveMQ, and create an export and then run ActiveMQ's JIRA in a separate JIRA instance? Once JIRA's import/export is enhanced we then could import the data into the main ASF instance. Thoughts? Regards, John
[jira] Unassigned Patches: week of 03-13-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 3 2006 - GERONIMO-1414 - Console About page does not set the shortcut icon Jan 4 2006 - GERONIMO-1418 - allow user to specify deployment targets by nickname Jan 6 2006 - GERONIMO-1392 - update additional samples redirect in geronimo website Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 8 2006 - GERONIMO-1163 - improve jmx debug console Jan 14 2006 - GERONIMO-1453 - GBeanOverride throws NullPointerException when more than one reference element specified Jan 19 2006 - GERONIMO-1498 - DriverDownloader.DriverInfo causes java.io.NotSerializableException during server shutdown Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 25 2006 - GERONIMO-1037 - Clicking on uninstall link in Applications management pages deletes the configuration without any confirmation from user Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Feb 13 2006 - GERONIMO-1623 - Preliminary port of the OpenWire C# into C++. Feb 14 2006 - GERONIMO-1518 - Installer - only copy jars needed by selected configuration Feb 16 2006 - GERONIMO-1634 - NoClassDefFoundError from Derby Log Viewer Feb 21 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Feb 21 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Feb 23 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Feb 26 2006 - GERONIMO-1653 - User friendly error message from GBeanInstance Mar 6 2006 - GERONIMO-1699 - jdom classes not available for information portlet Mar 6 2006 - GERONIMO-1700 - Web Console prints a stack trace when attempting to deploy an application that is already deployed.
[jira] Updated: (GERONIMO-1529) Console should display Geronimo Version
[ http://issues.apache.org/jira/browse/GERONIMO-1529?page=all ]
Matthias Schmidt updated GERONIMO-1529:
---
Attachment: showVersion.patch
This adds the Geronimo Version under Server/Information/Kernel
Console should display Geronimo Version
---
Key: GERONIMO-1529
URL: http://issues.apache.org/jira/browse/GERONIMO-1529
Project: Geronimo
Type: Improvement
Components: console, Logging
Versions: 1.0, 1.0-M5, 1.0-M4, 1.0-M3, 1.0-M2, 1.0-M1, 1.1, 1.2, 1.x
Reporter: Matthias Schmidt
Priority: Minor
Attachments: showVersion.patch
One should be able to figure out geronimo's Version by:
a) looking in the Console, perhaps under Server Info
b) looking in the Logfiles.
for a) one can do the following:
---
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java
2006-01-23 14:57:59.0 +0100
+++
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java.CHANGE
2006-01-23 15:02:27.0 +0100
@@ -34,6 +34,7 @@
import org.apache.geronimo.console.BasePortlet;
import org.apache.geronimo.console.util.PortletManager;
import org.apache.geronimo.management.geronimo.JVM;
+import org.apache.geronimo.console.GeronimoVersion;
/**
* Calculates various information about the server to display in the server
@@ -71,6 +72,8 @@
Date bootDate = jvm.getKernelBootTime();
svrProps.put(Kernel Boot Time, bootDate);
+svrProps.put(Geronimo Version, new
GeronimoVersion().GERONIMO_VERSION);
+
renderRequest.setAttribute(svrProps, svrProps);
jvmProps.put(Java Version, jvm.getJavaVersion());
---
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
2006-01-11 17:34:52.0 +0100
+++
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp.CHANGE
2006-01-23 15:06:42.0 +0100
@@ -5,6 +5,7 @@
script type='text/javascript'
src='/console-standard/dwr/engine.js'/script
script type='text/javascript' src='/console-standard/dwr/util.js'/script
+
portlet:defineObjects/
table width=100%
@@ -19,6 +20,10 @@
td class=MediumBackgroundKernel Up Time/td
td class=MediumBackgrounddiv id=portlet:namespace/UpTimeNot
Yet Available/div/td
/tr
+ tr
+td class=LightBackground width=20% nowrapGeronimo Version/td
+td class=LightBackground width=80%${svrProps['Geronimo
Version']}/td
+ /tr
/table
br
!--
--
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: ActiveMQ Graduation From Incubator
John Sisson wrote: Alan D. Cabrera wrote: This is not a vote, but simply a discussion about the graduation of ActiveMQ from the Incubator. The status file is located here: https://svn.apache.org/repos/asf/incubator/activemq/trunk/STATUS We are proactively seeking feedback in the interest of graduation. Regards, Alan In regards to the infrastructure items, IMHO JIRA is a critical service required by the project and should be run on ASF infrastructure. Some of the benefits of moving ActiveMQ's JIRA data to the ASF would be: * JIRA svn integration (ability to see svn changes associated with a JIRA issue) * Backups of JIRA data under ASF control Seems like now would be a good time to do this, but currently JIRA does not have the ability to import data for a single project from data exported from another JIRA instance ( http://jira.atlassian.com/browse/JRA-1604 ). Would it be practical to follow Jeff Turner's suggestion in https://issues.apache.org/jira/browse/INFRA-713 , e.g. downloading a copy of JIRA 'Standalone' (built-in hsql db), load the data into it, delete everything not relating to ActiveMQ, and create an export and then run ActiveMQ's JIRA in a separate JIRA instance? Once JIRA's import/export is enhanced we then could import the data into the main ASF instance. Thoughts? Sounds great. It seems that you have a good start on this. Thanks for volunteering! /me ducks out of the room... Regards, Alan
[jira] Resolved: (SM-281) ability to generate wsdl for proxied endpoints if not provided
[ http://jira.activemq.org/jira//browse/SM-281?page=all ] Guillaume Nodet resolved SM-281: Assign To: Guillaume Nodet Resolution: Fixed Author: gnodet Date: Mon Mar 13 08:19:00 2006 New Revision: 385586 URL: http://svn.apache.org/viewcvs?rev=385586view=rev Log: SM-218: ability generate wsdl for proxied endpoints if not provided + ability to specify a spring resource for the wsdl Added: incubator/servicemix/trunk/servicemix-http/src/test/resources/xbean/SoapService.wsdl incubator/servicemix/trunk/servicemix-http/src/test/resources/xbean/provider.wsdl Modified: incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpComponent.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpEndpoint.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpExternalEndpoint.java incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/HttpConsumerTest.java incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/HttpXBeanDeployerTest.java incubator/servicemix/trunk/servicemix-http/src/test/resources/xbean/xbean.xml ability to generate wsdl for proxied endpoints if not provided -- Key: SM-281 URL: http://jira.activemq.org/jira//browse/SM-281 Project: ServiceMix Type: New Feature Components: servicemix-http Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: ActiveMQ Graduation From Incubator
Alan, Others are commenting on the infrastructure issues still on the plate for ActiveMQ. And, yes, migrating out of JIRA is a PITA. Jeff is proposing that we end up running lots of JIRA instances because we have to pull in several sets of JIRA imports from atlassian, codehaus, and elsewhere. I have no idea when Atlassian will support single project imports from JIRA as it does from Bugzilla. On the community side, we're still a bit shy of Mentors on ActiveMQ (James is the only one, and we are looking for at least 3 per project), and the ASF community building is only just getting started. No PPMC, yet, for which we need more Mentors. There has been some concern about growth rate within the Incubator. Requiring 3+ Mentors to help oversee projects puts a natural, but scalable, limit on our growth. In the meantime, we have some growing pains, because projects are already here, and lack the resources. --- Noel
Re: exposing a jbi endpoint as a SOAP endpoint
On 3/13/06, Raffaele Spazzoli [EMAIL PROTECTED] wrote:
I did as you said and it worked, thanks.
There are still a couple of issue that I'd like to understand:
1. the SOAP-Http proxy service doesn't provide a wsdl. Do you think that
could be possible to take the wsdl of the proxied service strip the jbi
binding and put a SOAP-http binding?
Done. You should give it a try. It does not currenly generate the binding
informations,
only the http or soap address for the endpoint.
2. I configured the routing using the xbean file:
http:endpoint service=im:VinciService
endpoint=imhttp:VinciService
role=consumer
locationURI=http://localhost:8192/Service/VinciService;
defaultMep=http://www.w3.org/2004/08/wsdl/in-out;
soap=true /
I'd like to do the same using the standard connection definitions of the
jbi deployment descriptor of the service assembly. Does it make sense
and is it supported in serivicemix?
Connections are now fully supported, but I'm not really sure how you could
use them.
They have been rewritten last week.
A connection defines that when a component will send a message to the
consumer
endpoint (or interface), it will be routed to the given provider endpoint.
The main goal
is to be able to define service units that are independant of the provider
endpoints.
These endpoints are thus defined in the service assembly with connections.
connection
consumer endpoint-name=im:VinciServiceHttpPort
service-name=im:VinciService
/consumer
provider endpoint-name=im:VinciServiceJBIPort
service-name=im:VinciService
/provider
/connection
If I try to do it servicemix complains that it can't find the cosumer
service (the proxy), I believe it does is because the proxy service
doesn't register a wsdl, so back to the previous point.
About the service-common library I found it useful but not much
documented, it took me a couple of days of code reading to understand
what it could do for me.
Yeah, i know. I will try to put write some doc in the following weeks.
Last thing I suggest to add to the maven-servicemix-plugin a couple of goal
to help the deploy of install zip and service assemblies.
supposing to have a directory structure that mirrors the service assembly,
I did the following scripts that could be a start:
goal name=jbi:install prereqs=jbi:jbi description=install
installer in deploy directory of esb
ant:echoinstalling installer/ant:echo
ant:delete file=${maven.jbi.esb.dir}/install/${maven.jbi.final.name
}/
ant:copy file=${maven.build.dir}/${maven.jbi.final.name} todir=${
maven.jbi.esb.dir}/install /
/goal
goal name=jbi:deploy
prereqs=jbi:create-sa
description=deploy the serice assembies
ant:echodeploying sa/ant:echo
ant:delete file=${maven.jbi.esb.dir}/deploy/${jbi.assembly.name
}.zip/
ant:copy file=${basedir}/target/${jbi.assembly.name}.zip todir=${
maven.jbi.esb.dir}/deploy /
/goal
goal name=jbi:create-sa description=create the service assembly
j:set var=saname value=${jbi.assembly.name} /
j:set var=keysaname value=jbi.assembly.unitname.${saname} /
util:tokenize var=sus delim=,${context.getVariable
(keysaname)}/util:tokenize
ant:mkdir dir=${basedir}/target/jbi_sa_${saname} /
j:forEach var=su items=${sus}
log:infogenerate service unit zip file for ${su}/log:info
ant:zip
destfile=${basedir}/target/jbi_sa_${saname}/${su}.zip
basedir=${jbi.assembly.dir}/${
jbi.assembly.name}/${su}/
/j:forEach
ant:zip destfile=${basedir}/target/${
jbi.assembly.name}.zip
ant:zipfileset dir=${jbi.assembly.dir
}/${jbi.assembly.name}/META-INF prefix=META-INF/
ant:zipfileset dir=${basedir}/target/jbi_sa_${saname}
includes=*.zip/
/ant:zip
/goal
Good idea.
Thanks for the goals definitions ...
Cheers,
Guillaume Nodet
bye
Raffaele
On Thu, 2006-03-09 at 12:22 +0100, Guillaume Nodet wrote:
See comments inline
On 3/9/06, Raffaele Spazzoli [EMAIL PROTECTED] wrote:
I'm developing a binding component using the sericemix-common library
and taking inspiration (i.e. coping :-) )from the jsr181 component.
If you have concerns with the existing component (missing features,
bugs...),
please raise them.
It works and when I generate the wsdl for my deployed service I obtain a
jbi binding:
wsdl:binding name=VinciServiceJBIBinding
type=tns:VinciServicePortType
wsdlsoap:binding style=document
transport=http://java.sun.com/xml/ns/jbi/binding/service+engine/
wsdl:operation name=vinciOperation
wsdlsoap:operation soapAction=/
wsdl:input name=vinciOperationRequest
wsdlsoap:body use=literal/
/wsdl:input
[jira] Updated: (GERONIMO-1484) Display username who is logged into the Webconsole
[ http://issues.apache.org/jira/browse/GERONIMO-1484?page=all ] Matthias Schmidt updated GERONIMO-1484: --- Attachment: showUser.patch This replaces the Header Console Navigation with Console (username) Display username who is logged into the Webconsole -- Key: GERONIMO-1484 URL: http://issues.apache.org/jira/browse/GERONIMO-1484 Project: Geronimo Type: Improvement Components: console Versions: 1.0, 1.1, 1.2, 1.x Environment: applies to all Enviroments Reporter: Matthias Schmidt Priority: Minor Attachments: showUser.patch Display the user who is logged into the Webconsole might by handy, esp. when having something like a role-based administration concept. One can achieve this by putting a %=request.getRemoteUser()% somewhere in the JSP's, for example: applications/console-framework/src/webapp/WEB-INF/aggregation/TabNavigation.jsp I'm no Designer, so it's up to you guys where to put it. -- 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: ActiveMQ Graduation From Incubator
On 3/13/06, Hiram Chirino [EMAIL PROTECTED] wrote: I agree that we should work on getting our JIRA in the ASF infrastructure! But I don' think accomplishing that task should be gate the limit's a poddling from graduation from the incubator. Well, I do. At the end of the Incubation process, it must have all resources on ASF-standard resources or I will vote -1. I did a quick check and it seems even the Maven TLP's JIRA is not on Apache infrastructure. see: http://maven.apache.org/issue-tracking.html I would not look at Maven as a good example of where the lines should be drawn. -- justin
Re: ActiveMQ Graduation From Incubator
I'll start at thread on infrastructure to discuss how best to get the JIRA migration done. Regards, Hiram On 3/13/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 3/13/06, Hiram Chirino [EMAIL PROTECTED] wrote: I agree that we should work on getting our JIRA in the ASF infrastructure! But I don' think accomplishing that task should be gate the limit's a poddling from graduation from the incubator. Well, I do. At the end of the Incubation process, it must have all resources on ASF-standard resources or I will vote -1. I did a quick check and it seems even the Maven TLP's JIRA is not on Apache infrastructure. see: http://maven.apache.org/issue-tracking.html I would not look at Maven as a good example of where the lines should be drawn. -- justin -- Regards, Hiram
Re: ActiveMQ Graduation From Incubator
On Mar 13, 2006, at 8:16 AM, Noel J. Bergman wrote: Alan, Others are commenting on the infrastructure issues still on the plate for ActiveMQ. And, yes, migrating out of JIRA is a PITA. Jeff is proposing that we end up running lots of JIRA instances because we have to pull in several sets of JIRA imports from atlassian, codehaus, and elsewhere. I have no idea when Atlassian will support single project imports from JIRA as it does from Bugzilla. I agree it is important to have as much as possible on apache hardware. It was my understanding until I read this thread here, that infrastructure was fine with leaving JIRAs for imported projects hosted remotely until the JIRA had a better import tool. With the new possibility that Jeff Turner laid for an import, I think we should work on having one big import for everything that is moving or has moved from codehaus. This would let us grab the ActiveMQ, ServiceMix, OpenEJB, and XBean jiras. As with the other issues here, this is a NEW possibility that I for one wasn't even aware existed until John brought it up. I don't think we should hold this against the AMQ community. On the community side, we're still a bit shy of Mentors on ActiveMQ (James is the only one, and we are looking for at least 3 per project), and the ASF community building is only just getting started. No PPMC, yet, for which we need more Mentors. There has been some concern about growth rate within the Incubator. Requiring 3+ Mentors to help oversee projects puts a natural, but scalable, limit on our growth. In the meantime, we have some growing pains, because projects are already here, and lack the resources. I understand this concern and agree with the solution, but we should remember that AMQ entered the incubator before this was a rule, so I for one didn't think it appled to them, since they are so close to graduation. Anyway, I think we can easily get a few more people to be mentors. I certainly will volunteer, but I don't think I qualify due to the member restriction. -dain
RE: Using non-Sun JNDI/RMI service provider
David, Thank you for you advice. However I don't think the problem can be solved by adding a copy of the NamingProperties gbean to the client-system plan because the name of the initial context factory is hardcoded in the following source: modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:56: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); Therefore System.setProperty() overrides the property specified in the NamingProperties gbean. From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Friday, March 10, 2006 7:24 PM To: dev@geronimo.apache.org Subject: Re: Using non-Sun JNDI/RMI service provider On Mar 10, 2006, at 7:36 AM, Pavlenko, Andrey A wrote: Hi all, I want to configure Geronimo to use non-Sun JNDI/RMI service provider. But as I can see, the name of the initial context factory is hardcoded in the sources so it looks I can't customize it in any way. Is there a way I can plug my provider, and if not, can we think about how this customization can be implemented? The following is the list of sources containing hardcoded name of the provider: modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:56: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); modules/naming/src/test/org/apache/geronimo/naming/geronimo/GeronimoRootContextTest.java:33: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); modules/naming/src/test/org/apache/geronimo/naming/java/AbstractContextTest.java:48: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); modules/naming/src/test/org/apache/geronimo/naming/java/ThreadContextTest.java:53: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); modules/system/src/test/org/apache/geronimo/system/properties/NamingPropertiesTest.java:11: private static final String NAMING_FACTORY_INITIAL = com.sun.jndi.rmi.registry.RegistryContextFactory; I can never keep straight exactly what this setting does :-) Note that all but the first are in tests. Do you need to change those too or just the app client setting which is the only one used at runtime? The app client (runtime) use should be easy to eliminate by adding a copy of the NamingProperties gbean from the rmi-naming configuration plan to the client-system plan. You'd still have to rebuild the configurations to get the new value since at this time we can't override gbean attributes in the first-loaded plan. We could look into adding another configuration for the app client that included the NamingProperties and SystemProperties gbeans similar to the server rmi-naming configuration: then you could override the properties in a client-config.xml thanks david jencks Thanks Andrey Pavlenko Intel Middleware Products Division
Re: Using non-Sun JNDI/RMI service provider
On Mar 13, 2006, at 10:06 AM, Pavlenko, Andrey A wrote:David, Thank you for you advice.However I don't think the problem can be solved by adding a copy of the NamingProperties gbean to the client-system plan because the name of the initial context factory is hardcoded in the following source:modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:56: System.setProperty("java.naming.factory.initial", "com.sun.jndi.rmi.registry.RegistryContextFactory");Therefore System.setProperty(…) overrides the property specified in the NamingProperties gbean.Yes, I was very unclear. I was thinking we could remove the hardcoded properties in StaticJndiContextPlugin and instead use a SystemProperties or NamingProperties gbean in one of the client plans. If you can try this please enter a Jira issue with your results and a patch if it works :-)Many thanks,david jencks From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, March 10, 2006 7:24 PMTo: dev@geronimo.apache.orgSubject: Re: Using non-Sun JNDI/RMI service provider On Mar 10, 2006, at 7:36 AM, Pavlenko, Andrey A wrote:Hi all, I want to configure Geronimo to use non-Sun JNDI/RMI service provider.But as I can see, the name of the initial context factory is hardcoded in the sources so it looks I can't customize it in any way.Is there a way I can plug my provider, and if not, can we think about how this customization can be implemented?The following is the list of sources containing hardcoded name of the provider: modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:56: System.setProperty("java.naming.factory.initial", "com.sun.jndi.rmi.registry.RegistryContextFactory");modules/naming/src/test/org/apache/geronimo/naming/geronimo/GeronimoRootContextTest.java:33: System.setProperty("java.naming.factory.initial", "com.sun.jndi.rmi.registry.RegistryContextFactory");modules/naming/src/test/org/apache/geronimo/naming/java/AbstractContextTest.java:48: System.setProperty("java.naming.factory.initial", "com.sun.jndi.rmi.registry.RegistryContextFactory");modules/naming/src/test/org/apache/geronimo/naming/java/ThreadContextTest.java:53: System.setProperty("java.naming.factory.initial", "com.sun.jndi.rmi.registry.RegistryContextFactory");modules/system/src/test/org/apache/geronimo/system/properties/NamingPropertiesTest.java:11: private static final String NAMING_FACTORY_INITIAL = "com.sun.jndi.rmi.registry.RegistryContextFactory"; I can never keep straight exactly what this setting does :-) Note that all but the first are in tests. Do you need to change those too or just the app client setting which is the only one used at runtime? The app client (runtime) use should be easy to eliminate by adding a copy of the NamingProperties gbean from the rmi-naming configuration plan to the client-system plan. You'd still have to rebuild the configurations to get the new value since at this time we can't override gbean attributes in the first-loaded plan. We could look into adding another configuration for the app client that included the NamingProperties and SystemProperties gbeans similar to the server rmi-naming configuration: then you could override the properties in a client-config.xml thanksdavid jencks ThanksAndrey PavlenkoIntel Middleware Products Division
RE: Using non-Sun JNDI/RMI service provider
Ok, I'll try to create a patch. Thank you for your assistance! From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 9:24 PM To: dev@geronimo.apache.org Subject: Re: Using non-Sun JNDI/RMI service provider On Mar 13, 2006, at 10:06 AM, Pavlenko, Andrey A wrote: David, Thank you for you advice. However I don't think the problem can be solved by adding a copy of the NamingProperties gbean to the client-system plan because the name of the initial context factory is hardcoded in the following source: modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:56: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); Therefore System.setProperty() overrides the property specified in the NamingProperties gbean. Yes, I was very unclear. I was thinking we could remove the hardcoded properties inStaticJndiContextPlugin and instead use a SystemProperties or NamingProperties gbean in one of the client plans. If you can try this please enter a Jira issue with your results and a patch if it works :-) Many thanks, david jencks From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, March 10, 2006 7:24 PM To: dev@geronimo.apache.org Subject: Re: Using non-Sun JNDI/RMI service provider On Mar 10, 2006, at 7:36 AM, Pavlenko, Andrey A wrote: Hi all, I want to configure Geronimo to use non-Sun JNDI/RMI service provider. But as I can see, the name of the initial context factory is hardcoded in the sources so it looks I can't customize it in any way. Is there a way I can plug my provider, and if not, can we think about how this customization can be implemented? The following is the list of sources containing hardcoded name of the provider: modules/client/src/java/org/apache/geronimo/client/StaticJndiContextPlugin.java:56: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); modules/naming/src/test/org/apache/geronimo/naming/geronimo/GeronimoRootContextTest.java:33: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); modules/naming/src/test/org/apache/geronimo/naming/java/AbstractContextTest.java:48: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); modules/naming/src/test/org/apache/geronimo/naming/java/ThreadContextTest.java:53: System.setProperty(java.naming.factory.initial, com.sun.jndi.rmi.registry.RegistryContextFactory); modules/system/src/test/org/apache/geronimo/system/properties/NamingPropertiesTest.java:11: private static final String NAMING_FACTORY_INITIAL = com.sun.jndi.rmi.registry.RegistryContextFactory; I can never keep straight exactly what this setting does :-) Note that all but the first are in tests. Do you need to change those too or just the app client setting which is the only one used at runtime? The app client (runtime) use should be easy to eliminate by adding a copy of the NamingProperties gbean from the rmi-naming configuration plan to the client-system plan. You'd still have to rebuild the configurations to get the new value since at this time we can't override gbean attributes in the first-loaded plan. We could look into adding another configuration for the app client that included the NamingProperties and SystemProperties gbeans similar to the server rmi-naming configuration: then you could override the properties in a client-config.xml thanks david jencks Thanks Andrey Pavlenko Intel Middleware Products Division
Re: M2 migration status
On 3/10/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 2006/3/9, Henri Yandell [EMAIL PROTECTED]: The geronimo-spec-j2ee-deployment module was giving errors; but I realised I was building under JDK 1.5. It works fine under 1.4; so something for the future there perhaps. I think I've seen a way to make sure that M2 is used on Java 1.4. Now, there might be a way to leverage it and ensure Java 1.4 runtime. Next I get errors from the Geronimo :: Directory module; this is because I'm being a aggressive and turning off the snapshot repositories in the top pom. directory-asn1 depends on commons-test, which is unreleased. In this case the ideal solution is to set commons-test to test scope so it doesn't end up in the build - I'll work on getting that changed - or just having them not depend on commons-test :) Great. I'm looking forward to committing your patch ;) Fixed it at the other end. The commons-test dependency no longer gets passed along transitively. Now I find that everything builds from the top down - except for the 2 Tomcat tests that already appear to be being looked into. This is with the snapshot repositories commented out - they slow things down and seem to lead to errors that mean I have to keep repeating the build until they've finally downloaded things. There's some way to change their strategy I think - must look into this. Slowly moving axis-builder along. Looks like the Maven xmlbeans plugin depends on a snapshot version of xmlbeans, so that's irritating :) Hen
Re: M2 migration status
j2ee-builder done. I have also pruned the dependency lists for j2ee-builder and j2ee. Will update the patch now. Cheers Prasad On 3/13/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/10/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 2006/3/9, Henri Yandell [EMAIL PROTECTED]: The geronimo-spec-j2ee-deployment module was giving errors; but I realised I was building under JDK 1.5. It works fine under 1.4; so something for the future there perhaps. I think I've seen a way to make sure that M2 is used on Java 1.4. Now, there might be a way to leverage it and ensure Java 1.4 runtime. Next I get errors from the Geronimo :: Directory module; this is because I'm being a aggressive and turning off the snapshot repositories in the top pom. directory-asn1 depends on commons-test, which is unreleased. In this case the ideal solution is to set commons-test to test scope so it doesn't end up in the build - I'll work on getting that changed - or just having them not depend on commons-test :) Great. I'm looking forward to committing your patch ;) Fixed it at the other end. The commons-test dependency no longer gets passed along transitively. Now I find that everything builds from the top down - except for the 2 Tomcat tests that already appear to be being looked into. This is with the snapshot repositories commented out - they slow things down and seem to lead to errors that mean I have to keep repeating the build until they've finally downloaded things. There's some way to change their strategy I think - must look into this. Slowly moving axis-builder along. Looks like the Maven xmlbeans plugin depends on a snapshot version of xmlbeans, so that's irritating :) Hen
[jira] Updated: (GERONIMO-1706) Module migration to Maven2: j2ee
[ http://issues.apache.org/jira/browse/GERONIMO-1706?page=all ] Prasad Kashyap updated GERONIMO-1706: - Attachment: pom.xml Pruned the dependency list. Module migration to Maven2: j2ee Key: GERONIMO-1706 URL: http://issues.apache.org/jira/browse/GERONIMO-1706 Project: Geronimo Type: Sub-task Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Attachments: pom.xml -- 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-1713) Module migration to Maven2: j2ee-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1713?page=all ] Prasad Kashyap updated GERONIMO-1713: - Attachment: j2ee-builder.patch test-setup.zip The j2ee-builder.patch updates the pom.xml such that adequate test-setup can be done. The test-setup.zip file contains a test-setup.xml file that gets unzipped into the src/test directory. With these patches, this module now runs the tests successfully. It can be considered migrated. Cheers Prasad Module migration to Maven2: j2ee-builder Key: GERONIMO-1713 URL: http://issues.apache.org/jira/browse/GERONIMO-1713 Project: Geronimo Type: Sub-task Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Prasad Kashyap Attachments: j2ee-builder.patch, test-setup.zip -- 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] Assigned: (GERONIMO-1714) Module migration to Maven2: connector-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1714?page=all ] Prasad Kashyap reassigned GERONIMO-1714: Assign To: Prasad Kashyap Module migration to Maven2: connector-builder - Key: GERONIMO-1714 URL: http://issues.apache.org/jira/browse/GERONIMO-1714 Project: Geronimo Type: Sub-task Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Prasad Kashyap -- 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-1714) Module migration to Maven2: connector-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1714?page=all ] Prasad Kashyap updated GERONIMO-1714: - Attachment: connector-builder.patch test-setup.zip These patches fixes the test failures on connector-builder. The dependency list has been pruned. Module migration to Maven2: connector-builder - Key: GERONIMO-1714 URL: http://issues.apache.org/jira/browse/GERONIMO-1714 Project: Geronimo Type: Sub-task Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Prasad Kashyap Attachments: connector-builder.patch, test-setup.zip -- 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-1743) Deploy.bat doesn't accept any arguments and hence doesn't work.
Deploy.bat doesn't accept any arguments and hence doesn't work. --- Key: GERONIMO-1743 URL: http://issues.apache.org/jira/browse/GERONIMO-1743 Project: Geronimo Type: Bug Components: deployment Versions: 1.2 Environment: Windows xp Reporter: Joe Bohn Fix For: 1.2 There is a bug in the deploy script with the treatment of arguments. Basically, the arguments are stored in a variable called ARGS but the script later assumes they are in CMD_LINE_ARGS. -- 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-1743) Deploy.bat doesn't accept any arguments and hence doesn't work.
[ http://issues.apache.org/jira/browse/GERONIMO-1743?page=all ] Joe Bohn updated GERONIMO-1743: --- Attachment: 1743_DeployScript.patch minor fix to correct variable name error in deploy.bat Deploy.bat doesn't accept any arguments and hence doesn't work. --- Key: GERONIMO-1743 URL: http://issues.apache.org/jira/browse/GERONIMO-1743 Project: Geronimo Type: Bug Components: deployment Versions: 1.2 Environment: Windows xp Reporter: Joe Bohn Fix For: 1.2 Attachments: 1743_DeployScript.patch There is a bug in the deploy script with the treatment of arguments. Basically, the arguments are stored in a variable called ARGS but the script later assumes they are in CMD_LINE_ARGS. -- 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-1714) Module migration to Maven2: connector-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1714?page=comments#action_12370269 ] Anita Kulshreshtha commented on GERONIMO-1714: -- Good work! Would these test still work after the 'basedir' issue described here is fixed? http://jira.codehaus.org/browse/MSUREFIRE-71 Module migration to Maven2: connector-builder - Key: GERONIMO-1714 URL: http://issues.apache.org/jira/browse/GERONIMO-1714 Project: Geronimo Type: Sub-task Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Prasad Kashyap Attachments: connector-builder.patch, test-setup.zip -- 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: Summary? was: Session API....
Hi Hiram :-) Hiram Chirino wrote: On 3/9/06, *Jules Gosnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 3) I think that you are completely omitting one of the key players from this API. The Invocation. The goal of successful Session management is that Invocation and Session should meet somewhere in the cluster for the successful rendering/processing of a page/ rpc/whatever. The Invocation carries all the information that you may wish to a) intercept and process elsewhere, b) pass onto the Session management layer to aid in its decision making upon creation, retrieval and invalidation of a Session. Depending on how responsibilities are split between client container and Session manager, the session management layer may actually want to modify the return values in this Invocation - adding removing session cookies/attributes, changing ttls upon this attribute, changing the value of this attribute or altering other information within the Invocation that is used to integrate it better with the Client at the other end of the wire. All these interactions should be opaque to the client-container (Jetty/TC/ OpenEJB/...) and depend entirely on the implementation of the Client (or e.g. Http loadbalancer) and the session management layer. I think this generic Session API is trying to avoid getting into protocol specifics The Invocation type, that I am describing, is not bound to a specific protocol (note that I mention both web and tiers above) - but an abstraction over calls/rpcs/etc.. carried via a number of possible transports : Http, OpenEJB, IIOP, various WS transports... so it's main goal is to avoid defining a model for a Invocation. If the Invocation were bound to a specific protocol, I would agree - but it isn't. I do believe that it's goal that It exposes enough information such as where the session is located, so the protocol specific Session APIs can be built on top of it. So, we are beginning to reach a consensus here - the Session API is not an API for Session Management, but an API for a State Manager that a Session Manager might use. This is the conclusion that Greg and I came to in our discussions. Unfortunately, I think that this leaves half the problem in the client container's domain. Jetty, Tomcat, OpenEJB, Axis etc already exist in non-clustered form. What is needed is a Session Management API through which clustered Session Managers can be plugged into these containers, and others, and transparently and completely take over responsibility for all clustering behaviour. What a State Management API provides is not enough. The Container is left with the problem of talking to the implementation behind this API about issues such as Location. This chunk of Location-aware code may either be rewritten for each container, or somehow shared between them. If you are sensible and go for the second option, you find that half of your API (the piece concerning Location) is not being used by the client Containers, but only by your piece of shared code - i.e. it is drifting back from the API and into an area where it does not actually need to be exposed at alland that your shared code needs to either be packaged with every client-container or subsumed into your Session Manager - the latter being the most sensible outcome. Illustrations : 1). I don't think that the Location of a Session if of any relevance to the Consumer. Jetty/TC/ OpenEJB are simply interested in looking up a Session and using it. A number of classes in org.apache.geronimo.session talk in terms of Location. I see Location as an implementation detail. WADI will have trouble mapping to some of the assumptions that appear to be made in this part of the API. e.g. Locator.getSessionLocation() is not an efficient thing to do in WADI. It involves a round-trip to the owner of this section of the Location Map. When WADI wants to move a Session it sends a message to this node, which sends a message to the owner of the Session, which sends a message containing the Session to the node that made the request - 3 hops. This API would require a 4-hop trip - 1 rpc (2-hops) WADI could start caching that kind of location information and then it would not need RPC to get the data. Seems like knowing the location of a session would be crucial in making a desicion to redirect, proxy, or move the session. WADI does not need to RPC to get the data. This problem only arises for WADI in trying to implement the proposed API. WADI is designed as a Partitioned space, rather than a Shared cache, with associated consistency and invalidation issues, specifically to overcome the problems in scaling introduced by these issues. Introducing a cache-based solution here would just introduce all the problems that WADI is designed to resolve. The point that I am trying to
[jira] Reopened: (GERONIMO-1672) Migrate security module to M2
[ http://issues.apache.org/jira/browse/GERONIMO-1672?page=all ] Anita Kulshreshtha reopened GERONIMO-1672: -- Migrate security module to M2 - Key: GERONIMO-1672 URL: http://issues.apache.org/jira/browse/GERONIMO-1672 Project: Geronimo Type: Task Components: security Versions: 1.x Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Fix For: 1.x Attachments: pom.patch -- 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-1672) Migrate security module to M2
[ http://issues.apache.org/jira/browse/GERONIMO-1672?page=all ]
Anita Kulshreshtha updated GERONIMO-1672:
-
Attachment: pom.patch
m2-log4j.patch
Added m2-log4j.properties to create network.log. The following line changed in
pom.xml
log4j.configurationfile:/${basedir}/m2-log4j.properties/log4j.configuration
This uses 'basedir'. Since a bug in m2 does not set baseidr. It might be
necessary to execute set basedir=. on windows.
Migrate security module to M2
-
Key: GERONIMO-1672
URL: http://issues.apache.org/jira/browse/GERONIMO-1672
Project: Geronimo
Type: Task
Components: security
Versions: 1.x
Environment: All
Reporter: Anita Kulshreshtha
Assignee: Anita Kulshreshtha
Fix For: 1.x
Attachments: m2-log4j.patch, pom.patch, pom.patch
--
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: ActiveMQ Graduation From Incubator
Dain Sundstrom wrote: On Mar 13, 2006, at 8:16 AM, Noel J. Bergman wrote: Alan, Others are commenting on the infrastructure issues still on the plate for ActiveMQ. And, yes, migrating out of JIRA is a PITA. Jeff is proposing that we end up running lots of JIRA instances because we have to pull in several sets of JIRA imports from atlassian, codehaus, and elsewhere. I have no idea when Atlassian will support single project imports from JIRA as it does from Bugzilla. I agree it is important to have as much as possible on apache hardware. It was my understanding until I read this thread here, that infrastructure was fine with leaving JIRAs for imported projects hosted remotely until the JIRA had a better import tool. With the new possibility that Jeff Turner laid for an import, I think we should work on having one big import for everything that is moving or has moved from codehaus. This would let us grab the ActiveMQ, ServiceMix, OpenEJB, and XBean jiras. Is ActiveMQ and ServiceMix's JIRAs running at codehaus, it doesn't appear to be (tracert showed a different network path compared with codehaus)? As with the other issues here, this is a NEW possibility that I for one wasn't even aware existed until John brought it up. I don't think we should hold this against the AMQ community. I don't like holding up progress, but my concern is how much incentive the project would have to move JIRA after incubation and whether it would be better to do it now? Also no date has been given by Atlassian for when JIRA will have a better import tool - we could be waiting a while. The Has the project migrated to our infrastructure? item on the status page seems misleading/pointless if a number of the project's services are running on external systems. Glad to see Hiram has started a thread on Infrastructure to discuss the migration. John On the community side, we're still a bit shy of Mentors on ActiveMQ (James is the only one, and we are looking for at least 3 per project), and the ASF community building is only just getting started. No PPMC, yet, for which we need more Mentors. There has been some concern about growth rate within the Incubator. Requiring 3+ Mentors to help oversee projects puts a natural, but scalable, limit on our growth. In the meantime, we have some growing pains, because projects are already here, and lack the resources. I understand this concern and agree with the solution, but we should remember that AMQ entered the incubator before this was a rule, so I for one didn't think it appled to them, since they are so close to graduation. Anyway, I think we can easily get a few more people to be mentors. I certainly will volunteer, but I don't think I qualify due to the member restriction. -dain
Re: ActiveMQ Graduation From Incubator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: I understand this concern and agree with the solution, but we should remember that AMQ entered the incubator before this was a rule, so I for one didn't think it appled to them, since they are so close to graduation. 'So close to graduation'? Whence comes that? I think that proximity is still very much up in the air, particularly given Noel's opinion that .. and the ASF community building is only just getting started. No PPMC, yet, for which we need more Mentors. These have nothing to do with when it entered incubation; the need for a PPMC has been there right along, and the 'ASF community building' is a sine qua non. (I have no opinion, myself, about the degree of 'ASF community building' that has occurred in ActiveMQ.) - -- #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 iQCVAwUBRBYW95rNPMCpn3XdAQJuJwP8Cv+Waz8q0lTJMeHM72nTNNzeyBBjczGf y+2l6vKrY65ueZLXOOCEZ4lBEScfsYMaiZ/YuHBgd25Gq//SVqH6fnkRUK8V63JC 4ArlE4+ZKg/lvt1msCC2YeNiFZxG1nC1OB3iK4M+QncNDEJaDhFWxT7Vqz7vt1vY iN5arjQ6Mzc= =pzI1 -END PGP SIGNATURE-
Re: ActiveMQ Graduation From Incubator
On Mar 13, 2006, at 5:05 PM, Rodent of Unusual Size wrote: Dain Sundstrom wrote: I understand this concern and agree with the solution, but we should remember that AMQ entered the incubator before this was a rule, so I for one didn't think it appled to them, since they are so close to graduation. 'So close to graduation'? Whence comes that? I think that proximity is still very much up in the air, particularly given Noel's opinion that If you read the email history, you will see that it was stated that the new rules would only apply to projects close to gradation. So I hope you can see my point, regardless of if you agree with that point. .. and the ASF community building is only just getting started. No PPMC, yet, for which we need more Mentors. These have nothing to do with when it entered incubation; the need for a PPMC has been there right along, and the 'ASF community building' is a sine qua non. (I have no opinion, myself, about the degree of 'ASF community building' that has occurred in ActiveMQ.) When AMQ entered the incubator as a sponsored project from Geronimo, the current understanding of incubator rules was that AMQ would simply use the Geronimo pmc since the Geronimo pmc is expected to be the home for the project. Since then the incubator rules have been rewritten several time and based on the emails I saw today, the current rules that Noel is promoting (3+ mentors) hasn't even be approved by the incubator. I personally find this incredibly frustrating, so please take my comments with a grain of salt. If you ask me setting up a separate pmc for these projects is an incrediably bad idea. Our objective is to create a single community between Geronimo, ActiveMQ, OpenEJB, ServiceMix and WADI. Putting these projects into separate boxes makes this very difficult. I would like to know, why have the incubator rules changed to, in my opinion, force all projects TLP? Maybe the incubator is the wrong place to bring these types projects. Is there another process to bring in a project we plan on integrating? If not, maybe the board should consider setting something else up. -dain
Re: Summary? was: Session API....
The Invocation type, that I am describing, is not bound to a specific protocol (note that I mention both web and tiers above) - but an abstraction over calls/rpcs/etc.. carried via a number of possible transports : Http, OpenEJB, IIOP, various WS transports... Sounds interesting but a bit abstract. Got a link to something that shows me what this generic invocation thing looks like? so it's main goal is to avoid defining a model for a Invocation. If the Invocation were bound to a specific protocol, I would agree - but it isn't. I do believe that it's goal that It exposes enough information such as where the session is located, so the protocol specific Session APIs can be built on top of it. So, we are beginning to reach a consensus here - the Session API is not an API for Session Management, but an API for a State Manager that a Session Manager might use. This is the conclusion that Greg and I came to in our discussions. Unfortunately, I think that this leaves half the problem in the client container's domain. Jetty, Tomcat, OpenEJB, Axis etc already exist in non-clustered form. What is needed is a Session Management API through which clustered Session Managers can be plugged into these containers, and others, and transparently and completely take over responsibility for all clustering behaviour. What a State Management API provides is not enough. The Container is left with the problem of talking to the Yes, I don't think it's the full picture. But I do think the implementing clustered state management is one of the trickier parts to get implemented correctly. The main performance characteristics of the clustered solution will sit squarely on the implementation of the clustered state manager. Creating a clean interface into this level of functionality should allow for us to start with simple solution and evolve to more efficient implementations as time progresses. implementation behind this API about issues such as Location. This chunk of Location-aware code may either be rewritten for each container, or somehow shared between them. If you are sensible and go for the second option, you find that half of your API (the piece concerning Location) is not being used by the client Containers, but only by your piece of shared code - i.e. it is drifting back from the API and into an area where it does not actually need to be exposed at alland that your shared code needs to either be packaged with every client-container or subsumed into your Session Manager - the latter being the most sensible outcome. Suppose we do come up with 1 uber session manager that can handle all kinds of container, I still think it's a good idea if he used the state manager via a clean set of interfaces for the reasons outlined above. The upside is that if we can't find the perfect interface for an uber session manager that works with invocations, we can now have session managers that can be tailored for each container but still share the same state management layer. Illustrations : 1). I don't think that the Location of a Session if of any relevance to the Consumer. Jetty/TC/ OpenEJB are simply interested in looking up a Session and using it. A number of classes in Sometimes.. what about if they want to do a redirect? Why would they need to always look up a session and cause a state transfer at all? org.apache.geronimo.session talk in terms of Location. I see Location as an implementation detail. WADI will have trouble mapping to some of the assumptions that appear to be made in this part of the API. e.g. Locator.getSessionLocation() is not an efficient thing to do in WADI. It involves a round-trip to the owner of this section of the Location Map. When WADI wants to move a Session it sends a message to this node, which sends a message to the owner of the Session, which sends a message containing the Session to the node that made the request - 3 hops. This API would require a 4-hop trip - 1 rpc (2-hops) WADI could start caching that kind of location information and then it would not need RPC to get the data. Seems like knowing the location of a session would be crucial in making a desicion to redirect, proxy, or move the session. WADI does not need to RPC to get the data. This problem only arises for WADI in trying to implement the proposed API. WADI is designed as a Partitioned space, rather than a Shared cache, with associated consistency and invalidation issues, specifically to overcome the problems in scaling introduced by these issues. Introducing a cache-based solution here would just introduce all the problems that WADI is designed to resolve. Yes, but I still believe that the underling implementation can optimize out many of these issues. Another possible way to work around this is, If WADI assumes that the session manager never redirects, then it could implement it
[jira] Commented: (GERONIMO-1714) Module migration to Maven2: connector-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1714?page=comments#action_12370290 ] Prasad Kashyap commented on GERONIMO-1714: -- Au Contraire this works only when I do a System.getProperty(basedir). Let me run that testcase too and verify that. Module migration to Maven2: connector-builder - Key: GERONIMO-1714 URL: http://issues.apache.org/jira/browse/GERONIMO-1714 Project: Geronimo Type: Sub-task Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Prasad Kashyap Attachments: connector-builder.patch, test-setup.zip -- 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: Summary?
On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote:
David Blevins wrote:
Sorry, was referring to this thread. Seems like it's winding
down and just looking for a clear idea of what the current
thinking is.
David,
since you are here - a few SFSB questions...
what provisions does the EJB spec make for timing out of SFSBs, if
any ? what metadata does this require associated with each session ?
What I can recal is that you can't passivate a stateful bean in mid-
transaction. You must activate a stateful bean if a client attempts
to invoke it and the instance has not yet been timed out. And unlike
Entities, Stateful session bean data isn't required to survive a
server crash or restart.
what provisions/requirements over and above these does OpenEJB make/
have ?
Aside from lifecycle management, retrieval and timing out, what
other requirements might OpenEJB have for SFSB management ?
Nothing I can think of. Maybe you are looking for something very
specific.
I seem to remember that SFSBs need notification on activation/
passivation ? is this correct ? are any other notifications required ?
A notification before a passivation (ejbPassivate()/@PrePassivate)
and another after activation (ejbActivate()/@PostActivate).
Is it possible for one client to pass the handle of an SFSB to
another ? Does the spec touch on this ? Does it ever happen ?
I know that per spec, the client identity cannot change mid-
transaction. Aside from that we allow it.
Are Local SFSBs to be considered Serialisable/Passivatable/
Migratable or not ?
I think you may be thinking that a client using a Local vs Remote
interface to access a stateful bean has a different impact on the
stateful bean's lifecycle. The lifecycle is the same regardless of
how a client accesses it. In other words, there is no such thing as
a local or remote bean, just local or remote reference to beans.
and finally :
Would it be simple to change OpenEJB to use an SFSB handle that
included an ID to a 'SuperSession' (Object containing all Session
objects pertaining to a single client for a given Server) along
with an ID to particular 'SubSession' (The SFSB itself) within this
'SuperSession', instead of whatever scheme you currently use ?
That wouldn't be simple as we don't have any concept of provisioning
client ids aside from the optional security identity associated with
incoming calls. In general the spec isn't really strict on the
server's view of a client, it's more focused on a client's view of a
bean (e.g. server). That is to say, beans have strict and spelled
out identity rules whereas client's do not.
We could invent a universal client id concept but it would be a fair
amount of work to reconcile that concept across the various ways
people can invoke stateful beans; IIOP+IDL, IIOP+Remote interface,
Custom protocol + Remote interface, Local interface. Using just
Local interfaces, is the client id:
- The id of the servlet or ejb
- The id of the war or ejb-jar
- The id of the ear (if there is one)
- The id of the VM
Remote interfaces really get you in trouble as they have the same
questions, plus they can be invoked by j2ee app clients as well as
non-j2ee java clients, or even non-java clients via IDL/IIOP.
I guess I'm not sure at what level you are thinking when you say the
word client or what you'd be looking to get out of the concept.
That'd probably be the most productive way to look at the concept --
otherwise it becomes one of those existentialist what is a
component type of things.
looking forward to some interesting answers...
Hope they help!
-David
Jules
-David
On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
Looks good.
-dain
On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
Dain Sundstrom wrote:
My guess is we're going to need to add an event notification
system to
the Session APIs. What do you think about just crib off of
the servlet
ones. I think we could just smash the three session listener
interfaces into something like this:
public interface SessionListener extends Listener {
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void attributeAdded(SessionEvent event);
void attributeRemoved(SessionEvent event);
void attributeRemoved(SessionEvent event);
I think you mean:
void attributeReplaced(SessionEvent event);
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void sessionCreated(SessionEvent event)
void sessionDestroyed(SessionEvent event)
}
public class SessionEvent extends Event {
Session getSession();
String getName();
String getValue();
}
We would bind a listener with a method on the Locator:
void addSessionListener(SessionListener listener);
void removeSessionListener(SessionListener listener);
that would certainly do it - the only change I'd like to see
is that the
[jira] Commented: (GERONIMO-1714) Module migration to Maven2: connector-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1714?page=comments#action_12370292 ] Prasad Kashyap commented on GERONIMO-1714: -- OK. Verified. I ran that test too. I don't have that problem either with m1 or m2. Module migration to Maven2: connector-builder - Key: GERONIMO-1714 URL: http://issues.apache.org/jira/browse/GERONIMO-1714 Project: Geronimo Type: Sub-task Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Prasad Kashyap Attachments: connector-builder.patch, test-setup.zip -- 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: ActiveMQ Graduation From Incubator
On Mar 13, 2006, at 5:31 PM, Dain Sundstrom wrote: On Mar 13, 2006, at 5:05 PM, Rodent of Unusual Size wrote: Dain Sundstrom wrote: I understand this concern and agree with the solution, but we should remember that AMQ entered the incubator before this was a rule, so I for one didn't think it appled to them, since they are so close to graduation. 'So close to graduation'? Whence comes that? I think that proximity is still very much up in the air, particularly given Noel's opinion that If you read the email history, you will see that it was stated that the new rules would only apply to projects close to gradation. So I hope you can see my point, regardless of if you agree with that point. I just realized the size of the cross posting on this thread. To be specific, I am referring to the proposed new rules thread on the [EMAIL PROTECTED] list (which isn't even on this cross post). Of course, I can't point to a specific email that made this policy, but that was my understanding at the time. Official policy documents would be really nice, especially considering they take a huge amount of time to develop and would hopefully slow down the rate of change in the incubator. Sorry about that, -dain
Re: Summary? was: Session API....
On Mar 11, 2006, at 2:33 PM, Jules Gosnell wrote: David, If you can have a go at answering the questions I have posed about [Open]EJB in my other posting on this thread, I will merge your answers into the model I am carrying around in my head and dump it into an email as soon as I can. Then we can investigate and discuss the differences between WADI's approach to these problems and the proposed Session API. Ok, answered those questions. Here are my first-blush thoughts/ questions again on the summary you posted. I like the concept that clients can be made smarter or store information that will make the cluster that much more efficient. But I'm not sure what you'd need me to do for clients that are out of our control and potentially written in an entirely different language, i.e. CORBA and Web Services. Can you describe what considerations I'd have to add on my side of the fence to make that work? Thanks, David
[jira] Commented: (GERONIMO-1724) Module migration to Maven 2: client
[ http://issues.apache.org/jira/browse/GERONIMO-1724?page=comments#action_12370297 ] Prasad Kashyap commented on GERONIMO-1724: -- Jacek, I can't find any resources in src/java. Was that above comment meant for some other module ? Seems like the client module is good to be closed. Module migration to Maven 2: client --- Key: GERONIMO-1724 URL: http://issues.apache.org/jira/browse/GERONIMO-1724 Project: Geronimo Type: Sub-task Versions: 1.x Reporter: Jacek Laskowski It's a task to help keep track of the progress of the module build migration to Maven2 -- 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: Summary? was: Session API....
Sorry I've been a bit checked out lately... working on 1.1.
I think we all agree in the APIs for sessions themselves (i.e.,
everything but location), and we agree that we need an event
interface like this:
void addSessionListener(SessionListener listener);
void removeSessionListener(SessionListener listener);
public interface SessionListener extends Listener {
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void attributeAdded(SessionEvent event);
void attributeRemoved(SessionEvent event);
void attributeReplaced(SessionEvent event);
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void sessionCreated(SessionEvent event)
void sessionDestroyed(SessionEvent event)
}
public class SessionEvent extends Event {
Session getSession();
String getName();
String getOldValue();
String getNewValue();
}
We still disagree on how exactly you obtain the session object for a
given session id. I think the most important part of this
disagreement to solve first, is should we have an API to make the
redirect/proxy/move decision on a generic invocation object, or
should we have the session API know the location of the session (this
is what is does now, but this is not necessarily the final API).
Does everyone agree with this summary? If so, I suggest we add the
agreed upon event interface above and continue our discussion about
last contentious point.
-dain
Re: Summary? was: Session API....
+1 from me...looks like the right track.
Dain Sundstrom wrote:
Sorry I've been a bit checked out lately... working on 1.1.
I think we all agree in the APIs for sessions themselves (i.e.,
everything but location), and we agree that we need an event interface
like this:
void addSessionListener(SessionListener listener);
void removeSessionListener(SessionListener listener);
public interface SessionListener extends Listener {
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void attributeAdded(SessionEvent event);
void attributeRemoved(SessionEvent event);
void attributeReplaced(SessionEvent event);
void valueBound(SessionEvent event);
void valueUnbound(SessionEvent event);
void sessionCreated(SessionEvent event)
void sessionDestroyed(SessionEvent event)
}
public class SessionEvent extends Event {
Session getSession();
String getName();
String getOldValue();
String getNewValue();
}
We still disagree on how exactly you obtain the session object for a
given session id. I think the most important part of this disagreement
to solve first, is should we have an API to make the redirect/proxy/move
decision on a generic invocation object, or should we have the session
API know the location of the session (this is what is does now, but this
is not necessarily the final API).
Does everyone agree with this summary? If so, I suggest we add the
agreed upon event interface above and continue our discussion about last
contentious point.
-dain
[jira] Updated: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
[ http://issues.apache.org/jira/browse/GERONIMO-1686?page=all ] Bill Dudney updated GERONIMO-1686: -- Attachment: jee5_exp_servlet.patch the jee5_exp_servlet.patch is the patch to use to add servlet 2.5 to the jee5 spec project. this patch contains the LICENSE.txt and NOTICE.txt files as well as a verbatim copy of the xsd from the servlet spec pdf. Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work -- Key: GERONIMO-1686 URL: http://issues.apache.org/jira/browse/GERONIMO-1686 Project: Geronimo Type: New Feature Reporter: Bill Dudney Assignee: Jeff Genender Priority: Minor Attachments: jee5_exp.patch, jee5_exp_servlet.patch I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the week of 3/6/06. -- 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: Summary?
On Mar 13, 2006, at 6:54 PM, David Blevins wrote: On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote: Is it possible for one client to pass the handle of an SFSB to another ? Does the spec touch on this ? Does it ever happen ? I know that per spec, the client identity cannot change mid- transaction. Aside from that we allow it. My experience is that a SFSB is almost always tied to a single client (e.g. user). I have seen a few weird pieces of code that passed SFSBs between clients, but the reason I was looking at them was because that didn't work reliably. This is largely due to EJB2.1:7.5.8 which states: Clients are not allowed to make concurrent calls to a stateful session object. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client[7] if the client is a remote client, or the javax.ejb.EJBException if the client is a local client. This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean class. For the weird cases, we could add an option in the EJB container to not keep a specific SFSB deployment in the client session. -dain
[jira] Commented: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
[ http://issues.apache.org/jira/browse/GERONIMO-1686?page=comments#action_12370316 ] Jeff Genender commented on GERONIMO-1686: - Nice work. But I only see the servlet side of things, not JSPs. nevertheless I committed the servlet work. Good job. please advise about the JSPs. Adding geronimo-spec-servlet Adding geronimo-spec-servlet/LICENSE.txt Adding geronimo-spec-servlet/NOTICE.txt Adding geronimo-spec-servlet/pom.xml Adding geronimo-spec-servlet/src Adding geronimo-spec-servlet/src/main Adding geronimo-spec-servlet/src/main/java Adding geronimo-spec-servlet/src/main/java/javax Adding geronimo-spec-servlet/src/main/java/javax/servlet Adding geronimo-spec-servlet/src/main/java/javax/servlet/Filter.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/FilterChain.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/FilterConfig.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/GenericServlet.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/RequestDispatcher.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/Servlet.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletConfig.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletContext.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletContextAttributeEvent.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletContextAttributeListener.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletContextEvent.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletContextListener.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletException.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletInputStream.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletOutputStream.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletRequest.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletRequestAttributeEvent.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletRequestAttributeListener.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletRequestEvent.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletRequestListener.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletRequestWrapper.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletResponse.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/ServletResponseWrapper.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/SingleThreadedModel.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/UnavailableException.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/Cookie.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpServlet.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpServletRequest.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpServletRequestWrapper.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpServletResponse.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpServletResponseWrapper.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpSession.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpSessionActivationListener.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpSessionAttributeListener.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpSessionBindingEvent.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpSessionBindingListener.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpSessionContext.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpSessionEvent.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpSessionListener.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/HttpUtils.java Adding geronimo-spec-servlet/src/main/java/javax/servlet/http/LocalStrings.properties Adding geronimo-spec-servlet/src/main/resources Adding geronimo-spec-servlet/src/main/resources/javax Adding geronimo-spec-servlet/src/main/resources/javax/servlet Adding geronimo-spec-servlet/src/main/resources/javax/servlet/resources Adding geronimo-spec-servlet/src/main/resources/javax/servlet/resources/XMLSchema.dtd
