Re: Simplifying the deployment model
David Oren wrote: What I'd like to suggest is adding the ability to deploy directories -- that is, instead of having to package an application in a war or ear file and then deploying that file, the deployer will be given the full path where the application is located. The application will be added to Geronimo, will not be copied to the config-store directory (which will contain only the .ser files) and instead, will be run from its current directory. Sachin and I discussed something like this at OSCON, the challenge being how to simplify this kind of setup with applications that were more complex than straight JSP applications. For example, when the JSP used information from beans that were populated by EJB calls. The web containers (both Jetty and Tomcat) allow you to specify where the content root is located. During normal deployment we set that to be the location inside the config where we put the war's content (the deployer knows nothing about the internal layout of the config store) but there is no reason why this needs to be. The rough idea we discussed was to allow applications to be deployed as normal (so all the JDBC and EJB references get resolved as expected) but to change the way the content roots were defined to refer back to the original source tree. That way web content (primarily JSPs and static content) could be modified easily and the result of the change seen without needing to redeploy the application. The easiest way to implement this would be with an element in the web deployment plan that specified where the content root was; that would allow for applications (e.g. portal apps) containing multiple wars. Combined with the ability to restart the application (triggering for example servlet lifecycle events that would cause frameworks like struts to reload their configuration data) this seemed to fit the bill. Of course, we then got distracted and haven't started implementing yet :-) I have a very early proof of concept that enables this feature for web applications, and I can post it if there's any interest. I think there would be a lot of interest. Best way to post would be to open a JIRA and attach the jar/patch to it. Please make sure the contribute to Apache flag is set. I'd be happy to hear any comments on this idea, and also suggestions on what you think will be the cleanest way to go about implementing this. Look forward to seeing it. -- Jeremy
M5 - 24hr notice of branch
The subject says it all ;-) Jeff
Re: M5 - 24hr notice of branch
Special request from the Maven team:those doing deployment to java-repository using jar:deploy (this does not affect normal users), please ensure you are using maven-artifact-plugin 1.5.2 or above.If you are using
1.1-beta-2, it comes with the latest version.If you are using 1.0.2, you must install it. You can check what you have with maven --info.To install:maven plugin:download -DartifactId=maven-artifact-plugin -DgroupId=maven -Dversion=
1.5.2The reason for doing this is that all ${versions}, %entities and extend / elements will be properly resolved so the POM will be complete, and will enable Geronimo for transitive dependencies for Maven
2.x users - this is especially important if there are any new spec JARs going up.Thanks! If I can help any further, please let me know.Cheers,BrettOn 9/16/05,
Jeff Genender [EMAIL PROTECTED] wrote:
The subject says it all ;-)Jeff
[jira] Created: (GERONIMO-1014) problems getting the UserPrincipal for servlets and struts
problems getting the UserPrincipal for servlets and struts -- Key: GERONIMO-1014 URL: http://issues.apache.org/jira/browse/GERONIMO-1014 Project: Geronimo Type: Bug Environment: WinXP, Geronimo-M4 Reporter: Ludwig Laman When logging in to a simple servlet/struts application, getting the user is lost through session/cookies(I think) after transferring to another servlet/strut page, but the user is still logged in. I'm not sure why this is happening but it might be related to org.apache.geronimo.jetty.JAASJettyPrincipal class. -- 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-1014) problems getting the UserPrincipal for servlets and struts
[ http://issues.apache.org/jira/browse/GERONIMO-1014?page=all ] Ludwig Laman updated GERONIMO-1014: --- Attachment: sampleWebApp.war attached is a simple war file (taken from the whole servlet/struts application just to present a simple J2EE security authentication). problems getting the UserPrincipal for servlets and struts -- Key: GERONIMO-1014 URL: http://issues.apache.org/jira/browse/GERONIMO-1014 Project: Geronimo Type: Bug Environment: WinXP, Geronimo-M4 Reporter: Ludwig Laman Attachments: sampleWebApp.war When logging in to a simple servlet/struts application, getting the user is lost through session/cookies(I think) after transferring to another servlet/strut page, but the user is still logged in. I'm not sure why this is happening but it might be related to org.apache.geronimo.jetty.JAASJettyPrincipal class. -- 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-1014) problems getting the UserPrincipal for servlets and struts
[ http://issues.apache.org/jira/browse/GERONIMO-1014?page=comments#action_12329532 ] Ludwig Laman commented on GERONIMO-1014: This is how it goes: 1. Deploy the war. 2. Browse to http://localhost:8080/sampleWebApp 3. Login as system/manager 4. Browse to http://localhost:8080/sampleWebApp/index.jsp (pardon this but you're already logged in). This displays the jsp page and stating which user is logged in. In this case, It always say You are not currently logged in but you are inside the web-app already. 5. Click the user servlet and you should have a forbidden access. Now, click the admin servlet and you should have the access to the admin page. You should also see the authenticity of role against to users, which means that an admin user is logged-on. 6. Click the home link to go back to index.jsp, but still, it doesn't display which user is logged but the fact is an admin user is logged on. This is just a part of a sample application using servlet and struts. It was deployed to Tomcat 5 and Jetty 5.1.5 and both appservers performed the normal behavior for this webapp. I'm not sure if it has something to do with the principal for this kind of behavior. problems getting the UserPrincipal for servlets and struts -- Key: GERONIMO-1014 URL: http://issues.apache.org/jira/browse/GERONIMO-1014 Project: Geronimo Type: Bug Environment: WinXP, Geronimo-M4 Reporter: Ludwig Laman Attachments: sampleWebApp.war When logging in to a simple servlet/struts application, getting the user is lost through session/cookies(I think) after transferring to another servlet/strut page, but the user is still logged in. I'm not sure why this is happening but it might be related to org.apache.geronimo.jetty.JAASJettyPrincipal class. -- 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: svn commit: r289302 - /geronimo/devtools/trunk/modules/eclipse-plugin/assembly/maven.xml
do you really want to call it v1.0.0?
maybe tack on a -dev or something to indicate it's not a release?
On Sep 15, 2005, at 3:54 PM, [EMAIL PROTECTED] wrote:
Author: sppatel
Date: Thu Sep 15 12:54:49 2005
New Revision: 289302
URL: http://svn.apache.org/viewcvs?rev=289302view=rev
Log:
change binary dist zip name to geronimo-eclipse-plugin-1.0.0.zip
Modified:
geronimo/devtools/trunk/modules/eclipse-plugin/assembly/maven.xml
Modified: geronimo/devtools/trunk/modules/eclipse-plugin/assembly/
maven.xml
URL: http://svn.apache.org/viewcvs/geronimo/devtools/trunk/modules/
eclipse-plugin/assembly/maven.xml?
rev=289302r1=289301r2=289302view=diff
==
--- geronimo/devtools/trunk/modules/eclipse-plugin/assembly/
maven.xml (original)
+++ geronimo/devtools/trunk/modules/eclipse-plugin/assembly/
maven.xml Thu Sep 15 12:54:49 2005
@@ -43,7 +43,7 @@
goal name=zipdistribution
ant:echoPackaging deployable feature/ant:echo
- ant:zip destfile=${maven.build.dir}/geronimo-server-
adapter_${pom.currentVersion}.zip basedir=$
{feature.assembly.distributions.dir}/
+ ant:zip destfile=${maven.build.dir}/geronimo-eclipse-
plugin-${pom.currentVersion}.zip basedir=$
{feature.assembly.distributions.dir}/
/goal
goal name=deploy
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: svn commit: r289302 - /geronimo/devtools/trunk/modules/eclipse-plugin/assembly/maven.xml
Yeah, good call. For eclipse to be able to load the plugin it needs to
end in a version number. I can bump the versions down.
Geir Magnusson Jr. wrote:
do you really want to call it v1.0.0?
maybe tack on a -dev or something to indicate it's not a release?
On Sep 15, 2005, at 3:54 PM, [EMAIL PROTECTED] wrote:
Author: sppatel
Date: Thu Sep 15 12:54:49 2005
New Revision: 289302
URL: http://svn.apache.org/viewcvs?rev=289302view=rev
Log:
change binary dist zip name to geronimo-eclipse-plugin-1.0.0.zip
Modified:
geronimo/devtools/trunk/modules/eclipse-plugin/assembly/maven.xml
Modified:
geronimo/devtools/trunk/modules/eclipse-plugin/assembly/maven.xml
URL:
http://svn.apache.org/viewcvs/geronimo/devtools/trunk/modules/eclipse-plugin/assembly/maven.xml?rev=289302r1=289301r2=289302view=diff
==
--- geronimo/devtools/trunk/modules/eclipse-plugin/assembly/maven.xml
(original)
+++ geronimo/devtools/trunk/modules/eclipse-plugin/assembly/maven.xml
Thu Sep 15 12:54:49 2005
@@ -43,7 +43,7 @@
goal name=zipdistribution
ant:echoPackaging deployable feature/ant:echo
- ant:zip
destfile=${maven.build.dir}/geronimo-server-adapter_${pom.currentVersion}.zip
basedir=${feature.assembly.distributions.dir}/
+ ant:zip
destfile=${maven.build.dir}/geronimo-eclipse-plugin-${pom.currentVersion}.zip
basedir=${feature.assembly.distributions.dir}/
/goal
goal name=deploy
--Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: [Geronimo Wiki] Update of Eclipse Tools by JacekLaskowski
Jacek, yes there is an all in one package, but only for the .7 released versions. The current plugin won't build against .7 as there have been breaking API changes since then. Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Geronimo Wiki for change notification. The following page has been changed by JacekLaskowski: http://wiki.apache.org/geronimo/Eclipse_Tools The comment on the change is: A note about WTP 0.7 All-in-one pack -- == Step 1 - Software Prerequisites == - * [http://maven.apache.org Maven] + * [http://maven.apache.org Apache Maven] - * [http://subversion.tigris.org/ SubVersion] + * [http://subversion.tigris.org/ Subversion] * [http://java.sun.com J2SE 1.4.2] * [http://www.eclipse.org/webtools/ Eclipse Web Tools Platform] These are the prerequisites to install the Web Tools Platform. They must be downloaded and installed before WTP can be installed. See the WTP download page for the correct driver versions needed for Eclipse, EMF, GEF, and the Java EMF Model Runtime. Extract all of the download zips into the same root location. + + If you don't want to bother with all of the above Eclipse acronyms: EMF, GEF, etc. and their requisities, download WTP 0.7 All-in-one pack from http://download.eclipse.org/webtools/downloads/drops/R-0.7-200507290654/. + == Step 2 - Download Source ==
eclipse plugin version and release schedule?
To get some discussion going on release schedules... What version should we have the eclipse plugin at? Currently it stands at 1.0.0. To give you some background First off, Eclipse requires a pure version number, so we can't have 1.0.0-dev. If you go to any of the eclipse projects, you'll notice that after downloading a version, you cannot visually differentiate between a development version of a jar and its released version. Only by the actual download zip, are versions specified by including a date and build type in the zip. This is why on the download like I put the date in the link to indicate that it is a daily 1.0.0 development driver. Secondly, the update manager should be used to post official released versions and to move from one released version to another. To update with a daily version, you manually have to download the zip and extract it over the previous version. One other issue is do we want an official version for 1.0? The plugins WTP requirement won't have their 1.0 release until around December. So it will have to be based on a milestone driver of WTP. The WTP release schedule is as follows: M8-9/23 M9-11/18 1.0-by EOY So what does everyone prefer? (1) We keep 1.0.0, and have our final driver with or after WTP hits 1.0 so our official version is based on the WTP 1.0 offical version. On this 1.0.0 release the update manager will be available as a primary means of installing this official version. (2) We bump down the current version to something like 0.5.0, and this version will be an official version to go out with Geronimo 1.0 and be based on one of the milestone driver's of WTP. This offical version will also be available through the update manager. (3) Something else Based on this, we can decide what function we want in. For example if (2) is chosen, we just focus on stability with WTP M8/9, deployment scenarios, rather then development scenarios (editors, views etc). Thoughts??? Sachin
Re: GERONIMO-825
OpenEJB as well. The only test I did was ensure XMLBeans ran, and they were not any errors during generation. Matt Hogstrom wrote: Did you do this for Geronimo only or did you test OpenEJB as well? Sachin Patel wrote: In 2 of the geronimo schema files the imports' schemaLocation path are prefixed with /schema whereas in the other xsd's they are not. See 825 for Aaron's and David J.'s comments. The eclipse plugin requires the schema's and up to now I've had include hand modified copies of them in the plugin. Now that the plugin is mavenized I can extract these out from the repo during the build so I'm always in sync with Geronimo, but these prefixes need be removed so that EMF can read them as-is. The following two schema's should be fixed. modules\web-builder\src\schema\geronimo-web.xsd modules\security-builder\src\schema\geronimo-security.xsd These in OpenEJB should be fixed as well. openejb\modules\openejb-builder\src\schema\openejb-jar.xsd openejb\modules\openejb-builder\src\schema\corba-css-config_1_0.xsd openejb\modules\openejb-builder\src\schema\corba-tss-config_1_0.xsd I've locally modified the schemas by removing the /schema prefix, and running xmlbeans isn't affected. Would it be alright if I made this fix for geronimo-web.xsd and geronimo-security.xsd? Sachin
Re: GERONIMO-825
Ok...I can commit this for you so let me know when we're in sync. Sachin Patel wrote: OpenEJB as well. The only test I did was ensure XMLBeans ran, and they were not any errors during generation. Matt Hogstrom wrote: Did you do this for Geronimo only or did you test OpenEJB as well? Sachin Patel wrote: In 2 of the geronimo schema files the imports' schemaLocation path are prefixed with /schema whereas in the other xsd's they are not. See 825 for Aaron's and David J.'s comments. The eclipse plugin requires the schema's and up to now I've had include hand modified copies of them in the plugin. Now that the plugin is mavenized I can extract these out from the repo during the build so I'm always in sync with Geronimo, but these prefixes need be removed so that EMF can read them as-is. The following two schema's should be fixed. modules\web-builder\src\schema\geronimo-web.xsd modules\security-builder\src\schema\geronimo-security.xsd These in OpenEJB should be fixed as well. openejb\modules\openejb-builder\src\schema\openejb-jar.xsd openejb\modules\openejb-builder\src\schema\corba-css-config_1_0.xsd openejb\modules\openejb-builder\src\schema\corba-tss-config_1_0.xsd I've locally modified the schemas by removing the /schema prefix, and running xmlbeans isn't affected. Would it be alright if I made this fix for geronimo-web.xsd and geronimo-security.xsd? Sachin
Re: TriFork CORBA donation
Hi there, ...
It has been up to a slow start, but I have finally gotten something
rolling now.
As I have mentioned earlier, I wanted to redo the I/O subsystem, and
this is going quite well. The first milestone I am targeting is to
be able to do client side stream-based invocations; i.e. be able to
do invocations using a generated stub. This is a sufficiently small
thing that it is doable relatively quick (sigh), and also gets around
to do most of the hairy parts of I/O.
This part I am writing from scratch, since the new I/O transcends
most of this code. This part is quite close to completion, and if
someone wants to see the code I'd be happy to share it. Here, I have
some notes on the I/O system; ...
The I/O system is designed with the following properties:
- it eliminates copying (double buffering)
- i/o can be off-loaded to a separate selector thread
- nio/select is used to avoid having an active thread listening for
incoming messages
- transport buffers are allocated only once, and have fixed size.
- facilitate multiplexing requests and bidirectional invocations.
In this terminology, a transport (which may be a socket or an in-
memory pipe, for instance) has the following API:
interface Transport {
InputChannel getInputChannel();
OutputChannel getOutputChannel();
void setInputHandler(InputHandler handler);
void close();
void start();
void signalCondition(Object conditionKey, Object user_data);
Object waitForCondition(Object conditionKey);
}
Only one thread can have the input channel at one time, and only one
thread can have the output channel. Calls to getInputChannel(), and
getOutputChannel() will block until the channel is available. If
someone else has taken the channel, then the requestor will block
until the other party relinquishes it. This semantics is used to
handle multiplexing multiple client threads using the same transport
to do invocation, and similarily on the server side to handle
multiple threads sending responses.
interface Channel {
void close();
void relinquish();
}
Closing a channel semantically puts an end-of-stream marker into the
channel's data. For an OutputChannel, once the EOS reaches the
underlying transport layer (i.e. the data ahead of it has been
written), it is effectuated as a half-close. For an InputChannel,
the half-close is effectuated right away, and the client of the input
stream will read and end-of-file when there is no more buffered data
available.
When input becomes available in the underlying transport, and there
is no current thread that owns the input channel, then control is
passed to the input handler in a new thread taken from some worker pool.
The transport also has a built-in signaling mechanism, that allows
the InputHandler to parse a message header (including e.g. a
request_id) and then pass control to someone waiting for a given
reply. Such waiters can also participate in the processing of
available input.
An output channel allows you to put data into the transport, and
provides a mechanism to set markers. Markers are used to handle
fragmentation and other things where a size needs to be written into
some place in the stream.
interface OutputChannel extends Channel {
putByte(byte value);
put(byte[] data, int off, int len);
// ... other put methods ...
void flush();
OutputChannelMark setMark(OutputChannelMarkHandler handler);
}
Now, if the output channel's buffer runs full, then the mark handler
is called, so that the
interface OutputChannelMarkHandler {
void willFlush(OutputChannelMark mark);
}
OutputChannelMark provides a ByteBuffer-like view of the stream,
where index 0 is the position of the marker. You cannot put data
beyond the mark's limit, which is equal to the amount of bytes
written to the channel since the mark.
interface OutputChannelMark {
void putByte(int idx, byte value);
void putInt(int idx, int value);
int limit();
void release();
OutputChannel getOutputChannel();
}
Calling release() on an OutputChannelMark will release underlying
buffer space up to this mark (unless of cause there is a non-released
marker that was set earlier in the stream).
The OutputChannelMark can also give you the channel that i came from,
and so inside the handler you can do stuff like this to handle GIOP
fragmentation dynamically based on when the underlying buffer runs full.
class FragmentHandler implements OutputChannelMarkHandler {
void willFlush( OutputChannelMark mark) {
int message_size = mark.limit();
if (!logical_stream_has_ended) {
mark.putByte(7, 2); // write hasMoreFragments bit
}
mark.putInt (8, message_size); // write message size
into GIOP header
mark.release();
if (!logical_stream_has_ended) {
mark.getOutputChannel().setMark(this);
Re: [discussion] How do we get help with testing?
This is a great idea. Running the TCK is a huge pain for us and we have a very small matrix right now (2 version of geronimo * 1 platform * 1 Java VM). I was chatting with David Blevins about this yesterday, and he suggested that we make this a full subproject. The subproject could mange TCK and integration testing, hourly builds, nightly releases, daily performance tests with trade and spec and so on. We could create the supproject using the TCK build tree, the scripts tree, and itests modules. What do you think? -dain On Sep 14, 2005, at 2:45 AM, Geir Magnusson Jr. wrote: I'd like to discuss how we might expand our efforts in the area of testing and QA. Now that we're getting into the habit of J2EE certified releases, we have a much bigger testing load - we want to have more testing happening continuously between releases, and then at release time have a wide matrix of tested platforms. All of this takes work, lots of work. The short answer is that we need more people interested in testing, and we need to find a place for them in the project. Right now, our policy is that committers are able to get access to the TCK and participate on the private TCK mail list. I'd like to maintain this concept - that people with access to these materials and discussion have a demonstrable tie to the project - but I think we should discuss something along the lines of a QA committer, someone who can begin their participation in the project focused on testing (and of course over time move to whatever they show interested an aptitude in. It's a big, serious job (far bigger and far more serious than I ever thought), and we certainly need the help. Comments? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: GERONIMO-825
Cool. Thanks Matt. Would one of the other geronimo committers mind taking as sec and fixing up geronimo-web.xsd and geronimo-security.xsd? Thanks. Matt Hogstrom wrote: Ok...I can commit this for you so let me know when we're in sync. Sachin Patel wrote: OpenEJB as well. The only test I did was ensure XMLBeans ran, and they were not any errors during generation. Matt Hogstrom wrote: Did you do this for Geronimo only or did you test OpenEJB as well? Sachin Patel wrote: In 2 of the geronimo schema files the imports' schemaLocation path are prefixed with /schema whereas in the other xsd's they are not. See 825 for Aaron's and David J.'s comments. The eclipse plugin requires the schema's and up to now I've had include hand modified copies of them in the plugin. Now that the plugin is mavenized I can extract these out from the repo during the build so I'm always in sync with Geronimo, but these prefixes need be removed so that EMF can read them as-is. The following two schema's should be fixed. modules\web-builder\src\schema\geronimo-web.xsd modules\security-builder\src\schema\geronimo-security.xsd These in OpenEJB should be fixed as well. openejb\modules\openejb-builder\src\schema\openejb-jar.xsd openejb\modules\openejb-builder\src\schema\corba-css-config_1_0.xsd openejb\modules\openejb-builder\src\schema\corba-tss-config_1_0.xsd I've locally modified the schemas by removing the /schema prefix, and running xmlbeans isn't affected. Would it be alright if I made this fix for geronimo-web.xsd and geronimo-security.xsd? Sachin
Re: Simplifying the deployment model
On 9/16/05, David Oren [EMAIL PROTECTED] wrote: What I'd like to suggest is adding the ability to deploy directories -- that is, instead of having to package an application in a war or ear file and then deploying that file, the deployer will be given the full path where the application is located. The application will be added to Geronimo, will not be copied to the config-store directory (which will contain only the .ser files) and instead, will be run from its current directory. I believe it's better that all the files Geronimo accesses remain inside its directory hierarchy. As a newbie I used to edit files inside Tomcat directories, but then I realized it's a bad idea. To follow Tomcat deployment: how about a hot deploy directory where you could copy your WARs (and EARs later)
[jira] Commented: (GERONIMODEVTOOLS-12) NPE when publishing Web Service
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12?page=comments#action_12329565 ] Miguel A Paraz commented on GERONIMODEVTOOLS-12: I updated and rebuit. Same thing. The project is empty except for the bean file. I found that the Eclipse output is: In Pre service develop command. Sep 17, 2005 1:06:19 AM org.apache.axis.utils.JavaUtils isAttachmentSupported WARNING: Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled. In Pre service assemble command. In Pre service deploy command. In Pre service install command. In Pre service run command. NPE when publishing Web Service --- Key: GERONIMODEVTOOLS-12 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12 Project: Geronimo-Devtools Type: Bug Environment: latest HEAD, wtp-I20050914 and dependencies, Linux Reporter: Miguel A Paraz 1. Create a Dynamic Web Project, using Geronimo as server 2. Create a bean class. 3. New/Web Services/Web Service 4. Bottom up, defaults 5. Service Deployment Configuration: run time is Axis, server is Geronimo 6. Web Service Java Bean Identity: defaults, all methods, Document/Literal (Wrapped) 7. Start server 8. Error dialog box: Could not publish to the server. java.lang.NullPointerException at org.apache.geronimo.core.internal.GeronimoUtils.isWebModule(GeronimoUtils.java:78) at org.apache.geronimo.core.internal.GeronimoUtils.getConfigId(GeronimoUtils.java:62) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:368) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:281) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:632) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:685) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:586) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:705) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:694) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand$1.run(StartServerCommand.java:182) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand.publish(StartServerCommand.java:194) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand.execute(StartServerCommand.java:104) at org.eclipse.jst.ws.internal.consumption.ui.server.StartServerWidget$StartServerJob.run(StartServerWidget.java:305) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) -- 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-12) NPE when publishing Web Service
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12?page=comments#action_12329567 ] Sachin Patel commented on GERONIMODEVTOOLS-12: -- I imported you project, and I was able to deploy. 14:25:28,217 INFO [LocalConfigStore:config-store] Installed configuration sample-ws/sample-ws in location 25 14:25:28,297 INFO [LocalConfigStore:config-store] Loaded Configuration geronimo.config:name=sample-ws/sample-ws 14:25:28,357 INFO [Configuration] Started configuration sample-ws/sample-ws 14:25:28,578 INFO [PersistentConfigurationList] Saved running configuration list 14:25:28,608 INFO [Container] Started [EMAIL PROTECTED] 14:25:28,608 INFO [/sample-ws] JSR154 unwrappedDispatchSupported=true 14:25:28,608 INFO [JettyWebAppContext] JettyWebAppContext started 14:25:28,608 INFO [Container] Started WebApplicationContext[/sample-ws,sample-ws] Now, are you installing the webmodule standalone, or the ear? Perhaps, you're doing something I'm not thats causing the exception. Can you verify the steps above? I'm going to add some system outs and get send you a patch for you to try. NPE when publishing Web Service --- Key: GERONIMODEVTOOLS-12 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12 Project: Geronimo-Devtools Type: Bug Environment: latest HEAD, wtp-I20050914 and dependencies, Linux Reporter: Miguel A Paraz 1. Create a Dynamic Web Project, using Geronimo as server 2. Create a bean class. 3. New/Web Services/Web Service 4. Bottom up, defaults 5. Service Deployment Configuration: run time is Axis, server is Geronimo 6. Web Service Java Bean Identity: defaults, all methods, Document/Literal (Wrapped) 7. Start server 8. Error dialog box: Could not publish to the server. java.lang.NullPointerException at org.apache.geronimo.core.internal.GeronimoUtils.isWebModule(GeronimoUtils.java:78) at org.apache.geronimo.core.internal.GeronimoUtils.getConfigId(GeronimoUtils.java:62) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:368) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:281) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:632) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:685) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:586) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:705) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:694) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand$1.run(StartServerCommand.java:182) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand.publish(StartServerCommand.java:194) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand.execute(StartServerCommand.java:104) at org.eclipse.jst.ws.internal.consumption.ui.server.StartServerWidget$StartServerJob.run(StartServerWidget.java:305) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) -- 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-12) NPE when publishing Web Service
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12?page=comments#action_12329568 ] Sachin Patel commented on GERONIMODEVTOOLS-12: -- Also which wtp-I20050914 driver are you on? There were 3 on that day, and one of them had 118 compile errors. Perhaps you accidently pulled that one. NPE when publishing Web Service --- Key: GERONIMODEVTOOLS-12 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12 Project: Geronimo-Devtools Type: Bug Environment: latest HEAD, wtp-I20050914 and dependencies, Linux Reporter: Miguel A Paraz 1. Create a Dynamic Web Project, using Geronimo as server 2. Create a bean class. 3. New/Web Services/Web Service 4. Bottom up, defaults 5. Service Deployment Configuration: run time is Axis, server is Geronimo 6. Web Service Java Bean Identity: defaults, all methods, Document/Literal (Wrapped) 7. Start server 8. Error dialog box: Could not publish to the server. java.lang.NullPointerException at org.apache.geronimo.core.internal.GeronimoUtils.isWebModule(GeronimoUtils.java:78) at org.apache.geronimo.core.internal.GeronimoUtils.getConfigId(GeronimoUtils.java:62) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:368) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:281) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:632) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:685) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:586) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:705) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:694) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand$1.run(StartServerCommand.java:182) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand.publish(StartServerCommand.java:194) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand.execute(StartServerCommand.java:104) at org.eclipse.jst.ws.internal.consumption.ui.server.StartServerWidget$StartServerJob.run(StartServerWidget.java:305) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) -- 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-12) NPE when publishing Web Service
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12?page=comments#action_12329569 ] Sachin Patel commented on GERONIMODEVTOOLS-12: -- Actually there is already a trace statement in WTP that will give us the info that we need. Enable trace for org.eclipse.wst.server.core and rerun and during publish watch for... Publishing Module: modulename The NPE is coming from modulename, and if this is null, then the problem is in WTP and a bugzilla should be opened against wst.server. NPE when publishing Web Service --- Key: GERONIMODEVTOOLS-12 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-12 Project: Geronimo-Devtools Type: Bug Environment: latest HEAD, wtp-I20050914 and dependencies, Linux Reporter: Miguel A Paraz 1. Create a Dynamic Web Project, using Geronimo as server 2. Create a bean class. 3. New/Web Services/Web Service 4. Bottom up, defaults 5. Service Deployment Configuration: run time is Axis, server is Geronimo 6. Web Service Java Bean Identity: defaults, all methods, Document/Literal (Wrapped) 7. Start server 8. Error dialog box: Could not publish to the server. java.lang.NullPointerException at org.apache.geronimo.core.internal.GeronimoUtils.isWebModule(GeronimoUtils.java:78) at org.apache.geronimo.core.internal.GeronimoUtils.getConfigId(GeronimoUtils.java:62) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:368) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:281) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:632) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:685) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:586) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:705) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:694) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand$1.run(StartServerCommand.java:182) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand.publish(StartServerCommand.java:194) at org.eclipse.jst.ws.internal.consumption.command.common.StartServerCommand.execute(StartServerCommand.java:104) at org.eclipse.jst.ws.internal.consumption.ui.server.StartServerWidget$StartServerJob.run(StartServerWidget.java:305) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) -- 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: posted binaries
Sachin Patel wrote: I've posted a link to the unstable version of the eclipse plugin binary on the subproject site. Jacek, I've posted the build instructions on the wiki. You can get to it from the subproject site as well. Look forward on getting some feedback from you. Thanks! I'm trying to build the plugin, but it seems that the WTP All-in-one pack doesn't want to cooperate. org.eclipse.jst.j2ee.web-0.7.0.jar; path override doesn't exist: C:\projs\geronimo-devtools\eclipse\plugins\org.eclipse.jst.j2ee.web_0.7.0.jar org.eclipse.jst.j2ee.ejb-0.7.0.jar; path override doesn't exist: C:\projs\geronimo-devtools\eclipse\plugins\org.eclipse.jst.j2ee.ejb_0.7.0.jar org.eclipse.wst.common.modulecore-0.7.0.jar; path override doesn't exist: C:\projs\geronimo-devtools\eclipse\plugins\org.eclipse.wst.common.modulecore_0.7.0.jar org.eclipse.jst.j2ee-0.7.0.jar; path override doesn't exist: C:\projs\geronimo-devtools\eclipse\plugins\org.eclipse.jst.j2ee_0.7.0.jar It seems that some jars aren't available and they exist as directories. $ ls -d ~/c/projs/geronimo-devtools/eclipse/plugins/org.eclipse.jst.j2ee.web* /home/jlaskowski/c/projs/geronimo-devtools/eclipse/plugins/org.eclipse.jst.j2ee.web_0.7.0/ /home/jlaskowski/c/projs/geronimo-devtools/eclipse/plugins/org.eclipse.jst.j2ee.webservice_0.7.0/ /home/jlaskowski/c/projs/geronimo-devtools/eclipse/plugins/org.eclipse.jst.j2ee.webservices.ui_0.7.0/ Do you have any idea as to how to work it out? Sachin. Jacek
Re: [Geronimo Wiki] Update of Eclipse Tools by JacekLaskowski
Sachin Patel wrote: Jacek, yes there is an all in one package, but only for the .7 released versions. The current plugin won't build against .7 as there have been breaking API changes since then. So, is downloading all of the pieces one by one the only way to build the Eclipse plugin? Jacek
Re: posted binaries
The WTP All-in-one pack is only available for the .7 release which is quite old now. I've been working with WTP to ensure that all their plugins have been converted to jars, and this has been recently done for the ones listed below. Thats why the .7 all in one package no longer works. Plus there have been many breaking API changes since then, so the plugin will not build against it anyways. You will need to use a recent integration driver. Jacek Laskowski wrote: Sachin Patel wrote: I've posted a link to the unstable version of the eclipse plugin binary on the subproject site. Jacek, I've posted the build instructions on the wiki. You can get to it from the subproject site as well. Look forward on getting some feedback from you. Thanks! I'm trying to build the plugin, but it seems that the WTP All-in-one pack doesn't want to cooperate. org.eclipse.jst.j2ee.web-0.7.0.jar; path override doesn't exist: C:\projs\geronimo-devtools\eclipse\plugins\org.eclipse.jst.j2ee.web_0.7.0.jar org.eclipse.jst.j2ee.ejb-0.7.0.jar; path override doesn't exist: C:\projs\geronimo-devtools\eclipse\plugins\org.eclipse.jst.j2ee.ejb_0.7.0.jar org.eclipse.wst.common.modulecore-0.7.0.jar; path override doesn't exist: C:\projs\geronimo-devtools\eclipse\plugins\org.eclipse.wst.common.modulecore_0.7.0.jar org.eclipse.jst.j2ee-0.7.0.jar; path override doesn't exist: C:\projs\geronimo-devtools\eclipse\plugins\org.eclipse.jst.j2ee_0.7.0.jar It seems that some jars aren't available and they exist as directories. $ ls -d ~/c/projs/geronimo-devtools/eclipse/plugins/org.eclipse.jst.j2ee.web* /home/jlaskowski/c/projs/geronimo-devtools/eclipse/plugins/org.eclipse.jst.j2ee.web_0.7.0/ /home/jlaskowski/c/projs/geronimo-devtools/eclipse/plugins/org.eclipse.jst.j2ee.webservice_0.7.0/ /home/jlaskowski/c/projs/geronimo-devtools/eclipse/plugins/org.eclipse.jst.j2ee.webservices.ui_0.7.0/ Do you have any idea as to how to work it out? Sachin. Jacek
Re: [Geronimo Wiki] Update of Eclipse Tools by JacekLaskowski
Yes. Its the only way to be able to launch it too. So you have to grab each of the peices anyways. There will be an all-in-one package for WTP 1.0 so you don't have to. I'll talk to the WTP team to see if they can make one available for the next milestone at the end of the month. Jacek Laskowski wrote: Sachin Patel wrote: Jacek, yes there is an all in one package, but only for the .7 released versions. The current plugin won't build against .7 as there have been breaking API changes since then. So, is downloading all of the pieces one by one the only way to build the Eclipse plugin? Jacek
Re: M5 - 24hr notice of branch
Brett,
Have the changes been committed that make the Geronimo HEAD work
with 1.1-b2? Last time I noticed, you said we had some POMs that were not
valid I think.
Thanks,
Aaron
On Fri, 16 Sep 2005, Brett Porter wrote:
Special request from the Maven team:
those doing deployment to java-repository using jar:deploy (this does not
affect normal users), please ensure you are using maven-artifact-plugin
1.5.2 or above.
If you are using 1.1-beta-2, it comes with the latest version.
If you are using 1.0.2, you must install it. You can check what you have
with maven --info.
To install:
maven plugin:download -DartifactId=maven-artifact-plugin -DgroupId=maven
-Dversion=1.5.2
The reason for doing this is that all ${versions}, %entities and extend /
elements will be properly resolved so the POM will be complete, and will
enable Geronimo for transitive dependencies for Maven 2.x users - this is
especially important if there are any new spec JARs going up.
Thanks! If I can help any further, please let me know.
Cheers,
Brett
On 9/16/05, Jeff Genender [EMAIL PROTECTED] wrote:
The subject says it all ;-)
Jeff
Re: M5 - 24hr notice of branch
I believe Dain committed them the other day.Cheers,BrettOn 9/17/05, Aaron Mulder [EMAIL PROTECTED]
wrote:Brett,Have the changes been committed that make the Geronimo HEAD work
with 1.1-b2?Last time I noticed, you said we had some POMs that were notvalid I think.Thanks,AaronOn Fri, 16 Sep 2005, Brett Porter wrote: Special request from the Maven team:
those doing deployment to java-repository using jar:deploy (this does not affect normal users), please ensure you are using maven-artifact-plugin 1.5.2 or above. If you are using
1.1-beta-2, it comes with the latest version. If you are using 1.0.2, you must install it. You can check what you have with maven --info. To install: maven plugin:download -DartifactId=maven-artifact-plugin -DgroupId=maven
-Dversion=1.5.2 The reason for doing this is that all ${versions}, %entities and extend / elements will be properly resolved so the POM will be complete, and will enable Geronimo for transitive dependencies for Maven
2.x users - this is especially important if there are any new spec JARs going up. Thanks! If I can help any further, please let me know. Cheers, Brett On 9/16/05, Jeff Genender
[EMAIL PROTECTED] wrote: The subject says it all ;-) Jeff
[jira] Commented: (GERONIMO-1011) HTTPS Connectors fail on IBM JDK
[ http://issues.apache.org/jira/browse/GERONIMO-1011?page=comments#action_12329604 ] Jeremy Boynes commented on GERONIMO-1011: - Fixed in a slightly different way Sendingmodules/assembly/src/plan/j2ee-jetty-plan.xml Sendingmodules/assembly/src/plan/j2ee-tomcat-plan.xml Sending modules/jetty/src/java/org/apache/geronimo/jetty/connector/HTTPSConnector.java Sending modules/tomcat/src/java/org/apache/geronimo/tomcat/HttpsConnectorGBean.java Transmitting file data Committed revision 289691. This change allows the user to specify a value of Default for the algorithm which causes the connector to obtain the platform default from the KeyManagerFactory. This is standard Java and should work on any JVM. This does not affect the client-side behaviour. HTTPS Connectors fail on IBM JDK Key: GERONIMO-1011 URL: http://issues.apache.org/jira/browse/GERONIMO-1011 Project: Geronimo Type: Bug Components: JVM-compatibility Versions: 1.0-M5 Environment: WinXP or Win2003 Server w/ IBM 1.4.2 JDK Reporter: Donald Woods Attachments: IBMJUnit.patch, IBMSSL.patch HTTPS connectors for Jetty and Tomcat fail to load when starting the server using the IBM 1.4.2 JDK. This worked with M4, but was broken sometime in the last several weeks by changes in M5. The IBM JDK supplies its own HTTPS handler - com.ibm.net.ssl.www.protocol, which must be manually loaded in addition to the default sun.net.www.protocol. Also, the IBM JDK provides a different implementation of the X059 algorithm, which is IbmX509 instead of SunX509. The required code changes to recognize that an IBM JDK is being used and initialize the algorithm and protocol handler correctly, are confined to the Jetty and Tomcat HttpsConnector classes and the GeronimoURLFactory. The resolution of this bug will only allow a Geronimo server built with the Sun JDK to run on an IBM JDK - it does not resolve the other known build and Orb problems with using non-Sun JVMs. -- 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: M5 - 24hr notice of branch
I committed the patch and have been using 1.1-b2 for about a week now.
-dain
On Sep 16, 2005, at 6:01 PM, Brett Porter wrote:
I believe Dain committed them the other day.
Cheers,
Brett
On 9/17/05, Aaron Mulder [EMAIL PROTECTED] wrote:Brett,
Have the changes been committed that make the Geronimo HEAD
work
with 1.1-b2? Last time I noticed, you said we had some POMs that
were not
valid I think.
Thanks,
Aaron
On Fri, 16 Sep 2005, Brett Porter wrote:
Special request from the Maven team:
those doing deployment to java-repository using jar:deploy (this
does not
affect normal users), please ensure you are using maven-artifact-
plugin
1.5.2 or above.
If you are using 1.1-beta-2, it comes with the latest version.
If you are using 1.0.2, you must install it. You can check what
you have
with maven --info.
To install:
maven plugin:download -DartifactId=maven-artifact-plugin -
DgroupId=maven
-Dversion=1.5.2
The reason for doing this is that all ${versions}, %entities and
extend /
elements will be properly resolved so the POM will be complete,
and will
enable Geronimo for transitive dependencies for Maven 2.x users -
this is
especially important if there are any new spec JARs going up.
Thanks! If I can help any further, please let me know.
Cheers,
Brett
On 9/16/05, Jeff Genender [EMAIL PROTECTED] wrote:
The subject says it all ;-)
Jeff
Delete branches/v1_0_M4-QA
Anyone mind if I delete the old M4 QA branch? The correct M4 code is in tags/v1_0_M4, so this only leads to confusion (including mine earlier today). -dain
WTP trace mode (was Re: GERONIMODEVTOOLS-12) NPE when publishing Web Service)
On 9/17/05, Sachin Patel (JIRA) [EMAIL PROTECTED] wrote: Actually there is already a trace statement in WTP that will give us the info that we need. Enable trace for org.eclipse.wst.server.core and rerun and during publish watch for... Hi, Sorry but I could not find how to enable WTP trace. How is that done?
Re: [discussion] How do we get help with testing?
I would like to help testing. -- Dorileo On Wed, 2005-09-14 at 05:45 -0400, Geir Magnusson Jr. wrote: I'd like to discuss how we might expand our efforts in the area of testing and QA. Now that we're getting into the habit of J2EE certified releases, we have a much bigger testing load - we want to have more testing happening continuously between releases, and then at release time have a wide matrix of tested platforms. All of this takes work, lots of work. The short answer is that we need more people interested in testing, and we need to find a place for them in the project. Right now, our policy is that committers are able to get access to the TCK and participate on the private TCK mail list. I'd like to maintain this concept - that people with access to these materials and discussion have a demonstrable tie to the project - but I think we should discuss something along the lines of a QA committer, someone who can begin their participation in the project focused on testing (and of course over time move to whatever they show interested an aptitude in. It's a big, serious job (far bigger and far more serious than I ever thought), and we certainly need the help. Comments? geir
