[jira] Commented: (GERONIMO-1672) Migrate security module to M2
[ http://issues.apache.org/jira/browse/GERONIMO-1672?page=comments#action_12368662 ] Henri Yandell commented on GERONIMO-1672: - http://issues.apache.org/jira/browse/GERONIMO-1678 contains the patch to fix the interceptor problems by the way. > 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 > -- 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-1681) directory module migration to Maven2
[
http://issues.apache.org/jira/browse/GERONIMO-1681?page=comments#action_12368655
]
reghuram rajakumar vasanthakumari commented on GERONIMO-1681:
-
Hi,
I have written the pom.xml for directory module. I have used the
dependency plugin, please let me know whether
it has to be removed
[INFO] [compiler:compile]
Compiling 5 source files to
/opt/Workspace/Geronimo/Geronimo/modules/directory/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[copy] Copying 1 file to
/opt/Workspace/Geronimo/Geronimo/modules/directory/target/var
[INFO] Executed tasks
[INFO] [compiler:testCompile]
Compiling 1 source file to
/opt/Workspace/Geronimo/Geronimo/modules/directory/target/test-classes
[INFO] [surefire:test]
[INFO] Setting reports dir:
/opt/Workspace/Geronimo/Geronimo/modules/directory/target/surefire-reports
---
T E S T S
---
[surefire] Running org.apache.geronimo.directory.RunningTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.327 sec
[INFO] [jar:jar]
[INFO] Building jar:
/opt/Workspace/Geronimo/Geronimo/modules/directory/target/geronimo-directory-1.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/opt/Workspace/Geronimo/Geronimo/modules/directory/target/geronimo-directory-1.2-SNAPSHOT.jar
to
/root/.m2/repository/org/apache/geronimo/geronimo-directory/1.2-SNAPSHOT/geronimo-directory-1.2-SNAPSHOT.jar
[INFO] [maven-one-plugin:install-maven-one-repository {execution: default}]
[INFO] Installing
/opt/Workspace/Geronimo/Geronimo/modules/directory/target/geronimo-directory-1.2-SNAPSHOT.jar
to
/root/.maven/repository/org.apache.geronimo/jars/geronimo-directory-1.2-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 48 seconds
[INFO] Finished at: Fri Mar 03 10:51:15 IST 2006
[INFO] Final Memory: 10M/19M
[INFO]
regards
reghu
> directory module migration to Maven2
>
>
> Key: GERONIMO-1681
> URL: http://issues.apache.org/jira/browse/GERONIMO-1681
> Project: Geronimo
> Type: Sub-task
> Reporter: reghuram rajakumar vasanthakumari
> 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-1681) directory module migration to Maven2
[ http://issues.apache.org/jira/browse/GERONIMO-1681?page=all ] reghuram rajakumar vasanthakumari updated GERONIMO-1681: Attachment: pom.xml > directory module migration to Maven2 > > > Key: GERONIMO-1681 > URL: http://issues.apache.org/jira/browse/GERONIMO-1681 > Project: Geronimo > Type: Sub-task > Reporter: reghuram rajakumar vasanthakumari > 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] Commented: (GERONIMO-1681) directory module migration to Maven2
[ http://issues.apache.org/jira/browse/GERONIMO-1681?page=comments#action_12368651 ] reghuram rajakumar vasanthakumari commented on GERONIMO-1681: - please assign this task to me. > directory module migration to Maven2 > > > Key: GERONIMO-1681 > URL: http://issues.apache.org/jira/browse/GERONIMO-1681 > Project: Geronimo > Type: Sub-task > Reporter: reghuram rajakumar vasanthakumari > -- 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-1681) directory module migration to Maven2
directory module migration to Maven2 Key: GERONIMO-1681 URL: http://issues.apache.org/jira/browse/GERONIMO-1681 Project: Geronimo Type: Sub-task Reporter: reghuram rajakumar vasanthakumari -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JIRA and svn changes - how to tie it up?
Jacek Laskowski wrote: Hi, I've seen a couple of times that some JIRA issues where accompanied with svn changes. How can it be done? Jacek -- Jacek Laskowski http://www.laskowski.org.pl In your svn commit log message just needs to include the JIRA issue identifier, but hopefully followed by a comment describing the change for those looking at svn history. For example: GERONIMO-1605 - Display PID of started process when using geronimo.sh start or startup.sh (merged from trunk) The JIRA record GERONIMO-1605 will be updated (usually takes at least a few minutes after the commit) and the svn commits associated with the JIRA can be viewed by clicking on the "Subversion Commits" or "All" links in the JIRA issue. I usually use "All" so I can see the comments and history at the same time. If everyone did this it would make things much easier seeing the progress of work for an issue. It makes it easier tracking down and understanding the reason for changes made and whether the changes have also been made to a branch. Regards, John
Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
On Mar 1, 2006, at 11:55 PM, Greg Wilkins wrote: Dain Sundstrom wrote: Policy == So firstly we need SessionLocatoin.moveto(Server server), I'm confused. Why would we need that? There is an API to pull a session to a local node, but there is no API to push a session to a specific node. The use-case for the later if you have a load balancer that is a bit erratic and may scatter requests around a bit (think mod_jk after it has lost a node). If you have a policy where every node that receives a request pulls the session to it, then the session will expensively bounce around the cluster. This is something we talked about, and decided that no matter what you put in your system, you can always end up with a nomadic session. The solution to this is to slow the migration of the session so it doesn't have a negative impact on the system. Basically we implement a "don't move more often then every x minutes" policy in the system by letting the system that owns a session to refuse to let it be moved. Instead you can have a policy where you proxy (or redirect) the request to the node where the session is. This work fine, but at the cost of a proxy. If all or most of the requests are being sent to a specific node, then the session itself should be able to decide to migrate to that node: "I've been receiving most of my requests via node 7, so I think I'll move there". Thus we need a moveTo. I think a moveTo will also be useful for implementing shutdown policies, where you want to gently take a node out of a cluster. The policy should be able to be written independently of impl. I see the problem differently. I think the node that is proxying is paying the cost of the proxy. If that node, decides that proxying is getting two expensive, it can choose to moveLocally(). I see no need to have a push function. but more importantly, when we are redirecting or proxying requests, it would be good to be able to attach impl specific meta data to those requests. So the HTTP tier needs to be able to ask a SessionLocation for an opaque blob of meta data associated with a request and to be able to set that meta data when it recieves it. Huh? Redirect would be dependent on the web container so this would be a detail for the web container to deal with. The session apis, only says, "the session data is on server x". How the web container gets the request to server x is it's problem. I totally agree that it is the web-servers problem to move a request from one node to the other node. But I think there will be a need for some opaque impl specific data to be sent with that request - so the impl can coordinate it's actions. At the very least, it would be good for a request arriving on node x to be able to carry the opaque message: "I came from node z". It is easy for the web container to add such messages, but there is no way they can be passed to the policy impl. anyway... this is all getting very abstract... I think we(I) can let this slide a bit until there are some concrete policy implementation we can play with. Cool, I was getting really lost amyway :) -dain
Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
On Mar 1, 2006, at 11:54 PM, Greg Wilkins wrote: Dain Sundstrom wrote: + passivate ALL sessions (suspending node) That would happen under the covers of the session API (i.e., implementation specific) So if web container wants to undeploy a single context how does it passivate just one context in the map of maps? or how does the implementation know that it should passivate that? I guess the implementation could not passivate anything until all contexts are undeployed. But I'm still not sure how the web container tells the implementation that is undeploying sessions, but wants the contents saved for a later redeploy? I'm not overly concerned about this as (un)deployment is something that is going to involve more than just the session manager - but I still think a standard API for it would be good. This is a tradeoff decision. If we (the community), really thinks having the ability to handle this undeploy situation is wroth the complexity in the API then we add it. My personal opinion is we don't need this and I think it would be super complex to implement. I think it would require all servers deciding to remove an application at once. Now the above could be modelled with deep structure for the state associated with an ID, but not if all state for an ID has to be in one location. Having all of the state for a single session located on a single machine is a design assumption. We felt that if you wanted to let the data be divided across several machines it was not a single session session. But it is a common deployment to have the EJB on a different server to the web contexts ( I know it is not optimal ) If the session beans are going to be keyed under the same session id, then the one location does not work. If that's not a concern having the session ID map to a map of context to session is good for the web tier (aside from passivation concern). I think these are two different sessions. To me a session is a bucket of data for a single client, and that bucket can't be split. You do bring up a good point though. We need a way to make sure that when you are in a session on one server and pass invoke an ejb on another server that we do not use the same ID for the sessions. Session Management == There is nothing in the API to help with session management. Specifically: + last access time + access session (without actually modify state) + invalidate session + session timeouts + session events (eg session invalidation, passivation etc.) Other than last access time, I would classify this as implementation specific. The goal was to create a very very simply API that OpenEJB, ServiceMix, Lingo, Tuscany and web containers could use without haveing to know the internal details of the implementation. Does you code specifically need this or it is a nice to have? If it is the former, can you be a lot more specic on what the terms above mean (I'm not a web expert) :) These are all MUSTs as they are part of the servlet spec. Traditionally when clustering http sessions, it is the last access time that is the big PITA. It is updated on every request even if it does not ask for the session object. I guess the access time could be updated by a call to getSessionLocation, but that could make management difficult. Note that you don't want to put access time in with the other state, else you end up replicating the whole session state on every request. That is how I was thinking it would be done. The spec also requires that a session timeout be set in the web.xml and via the HttpSession API for an individual session. So my session manager will need a way to pass that to the implementation. Finally if the impl decides to passivate a session (for any number of reasons) then HttpSessionActivationListeners must be notified. So if I'm to write a SessionManager that just uses this API, then it needs something for all of the above. Sounds good. Can you propose some specific APIs? Also a little spec on what the apis are supposed to do would really help. I know this stuff can quickly go into the "gray area" :) Locking === I'm also not sure about the semantics of release(). If I'm writing a session manager, I'm not sure if I should be making the decision of when to release - that is very much implementation dependent. Some will replicate/sync on a setState, others will do it at the end of every request, other will do it every n seconds others will do it when the session is idle (has no requests). Instead of commanding "release", perhaps the API should allow the concept of a thread entering and existing a session scope: runInSessionScope(Runnable doSomething or enterSessionScope() leaveSessionScope() individual implementations can decide what locking they implement behind the scenes. That is exactly how the API works. When you start using a session you need to acquire it using the Locator and w
[jira] Created: (GERONIMO-1680) MDB without activation-config in openejb-jar.xml silently fails
MDB without activation-config in openejb-jar.xml silently fails --- Key: GERONIMO-1680 URL: http://issues.apache.org/jira/browse/GERONIMO-1680 Project: Geronimo Type: Bug Components: OpenEJB, ActiveMQ Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1, 1.0.1 I created a queue and sent a couple messages to it. Then I created an MDB with a message-destination-type of javax.jms.Queue and a message-destination-link pointing to a message-destination with the name of the Queue. It seems like this is enough information to point the MDB to that queue, assuming that openejb-jar.xml lists the resource adapter for the MDB. This deployed successfully, but no messages were received by the MDB. Adding an activation-config section to openejb-jar.xml fixed the problem -- the pending messages were received during deployment. One of these two issues strikes me as a bug: 1) Why wasn't the MDB hooked up to the queue without needing an activation-config block in openejb-jar.xml? 2) If that's an error, why is activation-config optional for an MDB in openejb-jar.xml and why didn't it cause a deployment error? In any case, I think deployment should always fail if an MDB is not actually hooked up to a destination. -- 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-1666) Console issues resulting from configID changes
[ http://issues.apache.org/jira/browse/GERONIMO-1666?page=all ] Paul McMahan updated GERONIMO-1666: --- Description: This JIRA tracks what areas of the console need attention as a result of the configID changes. At Revision 382401: - Classloader for classes loaded from geronimo-console-core-1.1-SNAPSHOT.jar can't load classes from geronimo-jetty-1.1-SNAPSHOT.jar. This prevents BasicProxyManager from being able to create proxies needed by the Server Logs and Web Server portlets. - J2EEServerImpl.getRepositories() returns an empty String[]. This prevents the the Common Libraries portlet and the DB Pool Wizard from listing out the available jars in the repository. Also prevents the JMS Resource portlet from being able to create new JMS Resource groups for ActiveMQ. - Trying to delete a new activeio listener I created results in the following ST. BTW, it failed to start too but I see that problem in Geronimo-1.0 16:19:56,029 WARN [Util] No parents found for geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,J2EEServer=geronimo,broker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.9123-asdf 16:19:56,030 ERROR [ActiveMQManagerGBean] Unable to remove GBean java.lang.NullPointerException at org.apache.geronimo.kernel.basic.BasicKernel.createGBeanName(BasicKernel.java:427) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:177) at org.activemq.gbean.management.ActiveMQManagerGBean.removeConnector(ActiveMQManagerGBean.java:247) at org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.invoke() - ConfigurationManager.listStores() returns an empty list for the storeName: geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Local This prevents the user from being able to start/stop/undeploy/etc their components from the EAR, WAR, EJB, Connector, App Client, and System Modules portlets - Deploying a simple WAR fails with an external plan fails with the error message: org.apache.geronimo.kernel.config.InvalidConfigException: Source is not readable /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/repository/test/test/1.1/test-1.1.war Source is not readable /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/repository/test/test/1.1/test-1.1.war I checked and the .../repository/test/test/1.1 directory is present but it is empty - Creating and then deploying a new security realm fails with the following ST: 17:20:06,704 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.kernel.repository.Version.parseVersion(Version.java:115) at org.apache.geronimo.kernel.repository.Version.(Version.java:40) at org.apache.geronimo.kernel.repository.Artifact.(Artifact.java:38) at org.apache.geronimo.deployment.service.EnvironmentBuilder.toArtifact(EnvironmentBuilder.java:229) at org.apache.geronimo.deployment.service.EnvironmentBuilder.buildEnvironment(EnvironmentBuilder.java:56) at org.apache.geronimo.deployment.service.EnvironmentBuilder.buildEnvironment(EnvironmentBuilder.java:125) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.getConfigurationID(ServiceConfigBuilder.java:147) The relevant part of the plan (which was generated by the wizard) looks like: Unspecified test was: This JIRA tracks what areas of the console need attention as a result of the configID changes. At Revision 382129: - Classloader for classes loaded from geronimo-console-core-1.1-SNAPSHOT.jar can't load classes from geronimo-jetty-1.1-SNAPSHOT.jar. This prevents BasicProxyManager from being able to create proxies needed by the Server Logs and Web Server portlets. - J2EEServerImpl.getRepositories() returns an empty String[]. This prevents the the Common Libraries portlet and the DB Pool Wizard from listing out the available jars in the repository. - Trying to delete a new activeio listener I created results in the following ST. BTW, it failed to start too but I see that problem in Geronimo-1.0 16:19:56,029 WARN [Util] No parents found for geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,J2EEServer=geronimo,broker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.9123-asdf 16:19:56,030 ERROR [ActiveMQManagerGBean] Unable to remove GBean java.lang.NullPointerException at org.apache.geronimo.kernel.basic.BasicKernel.createGBeanName(BasicKernel.java:427) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:177) at org.activemq.gbean.management.ActiveMQManagerGBean.
Re: Migrating to maven 2
On 3/1/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Cool. > > What does "converted" mean? > Does it mean that all unit tests pass? I'm presuming it means: Red -> No pom exists in SVN Yellow -> Pom exists in SVN, but mvn install fails Green -> Pom exists in SVN and a mvn install succeeds (compile/tests) Comments would then be used to indicate for times when there are m1-build tests that aren't being run etc. > How about conversion to the maven2 directory structure? Post having an m2 build I'd suggest. New modules (interceptor) do seem to be using the maven2 directory structure, but that's easy to get around. Hen
[jira] Commented: (GERONIMO-1677) geronimo-dependency-plugin deletion
[ http://issues.apache.org/jira/browse/GERONIMO-1677?page=comments#action_12368611 ] Henri Yandell commented on GERONIMO-1677: - Are you suggesting that the m1 use of the plugin would also go away? ie: 1.5: Remove dependency plugin from project.xml etc. > geronimo-dependency-plugin deletion > --- > > Key: GERONIMO-1677 > URL: http://issues.apache.org/jira/browse/GERONIMO-1677 > Project: Geronimo > Type: Sub-task > Reporter: 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] Commented: (GERONIMO-1672) Migrate security module to M2
[ http://issues.apache.org/jira/browse/GERONIMO-1672?page=comments#action_12368608 ] Henri Yandell commented on GERONIMO-1672: - just submitted a patch to fix interceptor. by my reckoning, security is the next blocker build-wise. Looking forward to seeing your patch :) > 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 > -- 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-1679) Typo in j2ee-builder's project.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1679?page=all ] Henri Yandell updated GERONIMO-1679: Attachment: GERONIMO-1679.patch It's simple, but adding a patch for the sake of it. > Typo in j2ee-builder's project.xml > -- > > Key: GERONIMO-1679 > URL: http://issues.apache.org/jira/browse/GERONIMO-1679 > Project: Geronimo > Type: Bug > Components: buildsystem > Reporter: Henri Yandell > Priority: Trivial > Attachments: GERONIMO-1679.patch > > Very minor, but caused me confusion when analysing the build order. > j2ee-builder thinks it is Geronimo :: J2EE and not Geronimo :: J2EE :: Builder -- 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-1679) Typo in j2ee-builder's project.xml
Typo in j2ee-builder's project.xml -- Key: GERONIMO-1679 URL: http://issues.apache.org/jira/browse/GERONIMO-1679 Project: Geronimo Type: Bug Components: buildsystem Reporter: Henri Yandell Priority: Trivial Attachments: GERONIMO-1679.patch Very minor, but caused me confusion when analysing the build order. j2ee-builder thinks it is Geronimo :: J2EE and not Geronimo :: J2EE :: Builder -- 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-1678) Interceptor module added to m1, needs same for m2
[ http://issues.apache.org/jira/browse/GERONIMO-1678?page=all ] Henri Yandell updated GERONIMO-1678: Attachment: GERONIMO-1678.patch Interceptor's pom was broken, and webservices + naming didn't know they were meant to use it, so fixed interceptor, added it to the top level pom and hooked it into naming and webservices. > Interceptor module added to m1, needs same for m2 > - > > Key: GERONIMO-1678 > URL: http://issues.apache.org/jira/browse/GERONIMO-1678 > Project: Geronimo > Type: Sub-task > Reporter: Henri Yandell > Attachments: GERONIMO-1678.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
Openwire CPP IFR headers
Hi Everybody, I just recently added the IFR smart pointer cpp headers to svn that the openwire cpp library was dependent on. I was previously not sure if we could include external sources but cliff's doc clear this issue up for me: http://people.apache.org/~cliffs/3party.html Regards, Hiram
Re: Recent OpenWire changes
Mats, That's correct. Regards, Hiram On Mar 2, 2006, at 7:39 AM, Mats Forslöf wrote: Most informative, thanks Hiram. Is it correct that the C# client only supports tight marshalling at the moment? Regards, Mats -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: den 1 mars 2006 19:26 To: activemq-dev@geronimo.apache.org Subject: Recent OpenWire changes Hi Everybody, Just a quick heads up, openwire by default tries to encode commands as tight as possible on the wire to decrease bandwidth requirements. To do this, it currently uses a 2 pass algorithm where the first pass collects all boolean writes into a bit array and pre calculates the size of the command on the wire. The second pass writes the command to the stream. While this produces small on the wire size, it's a bit CPU intensive, so I made a change so that a loose encoding is also possible which marshals the messages in a single pass and avoids doing all the fancy things that the tight encoding was using. Using loose encoding should make sense if your broker is CPU bound and network bandwidth is not an issue. So if you look at the open wire classes you will now see a bunch of tightMarshal/Unmarshal and looseMarshal/Unmarshal methods. Another option that has been added is the ability to omit the command size prefix on the serialized commands. The command size prefix is actually only useful for non blocking implementations where we only want to unmarshal the command once it has been fully received. In normal blocking IO, knowing the size of the command in not necessary. By omitting the command size, we should be able to do more efficient marshaling of the command since we don't have to calculate the command size beforehand. These default options are still at what they were before (tight encoding and command size prefixing), but they can be negotiated between the client and server with the WireFormatInfo packet. Regards, Hiram
[jira] Created: (GERONIMO-1678) Interceptor module added to m1, needs same for m2
Interceptor module added to m1, needs same for m2 - Key: GERONIMO-1678 URL: http://issues.apache.org/jira/browse/GERONIMO-1678 Project: Geronimo Type: Sub-task Reporter: Henri Yandell -- 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-1677) geronimo-dependency-plugin deletion
[ http://issues.apache.org/jira/browse/GERONIMO-1677?page=comments#action_12368602 ] Prasad Kashyap commented on GERONIMO-1677: -- The geronimo-dependency-plugin is used by the following 6 maven.xml files in modules/axis modules/directory modules/installer-processing modules/installer-support modules/jetty modules/tomcat Some dependencies in the the project.xml of the above modules are tagged with a property that is set to true. Based on this property, the plugin generates a geronimo-service.xml in the target/etc/META-INF directory of these modules for inclusion with the module's jar. The deps listed in the geronimo-service.xml files are used by the configuration and the configuration classloader pulls into the same classloader. Issues: --- 1. Dain has some plans for classloader changes at which point we don't know what will happen. 2. The element that was available under project.xml is no longer available under the pom.xml. So we can't mark those deps the same way. 3. m2 has transitive deps. Maybe once the deps get pruned, there is no need for a separate geronimo-service.xml. Maybe the pom.xml itself will then be good enough. Proposed Solution (to be implemented in this JIRA) --- 1. We should check in the already generated geronimo-service.xml files into the src tree of the above modules. These files should be packaged with the modules' jars. 2. We should add a comment for those special dependencies in the above 6 modules in the migrated pom.xml in case an equivalent generation has to be done in m2. 3. delete geronimo-dependency-plugin ? > geronimo-dependency-plugin deletion > --- > > Key: GERONIMO-1677 > URL: http://issues.apache.org/jira/browse/GERONIMO-1677 > Project: Geronimo > Type: Sub-task > Reporter: 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
Re: boot problem
No this is not something XBean has addressed. In the future we are going to lean on maven artifact for dependency resolution, and I think they have a way to have artifacts with multiple jar files each of which is targeted to a specific jvm version. -dain On Mar 2, 2006, at 12:07 AM, Matt Hogstrom wrote: In HEAD now and 1.1 when it comes out there will be a message indicating if the JDK level your using isn't supported so people will at least have a heads up. Given JDK 6 is on the horizon this sounds like an additional dependency. Dain, does XBean have this as one of the attributes so a check can be made? I'd hate to see multiple CARs (one for each JVM level). Paul McMahan wrote: Based on the number of problems people have encountered trying to use the 1.5 JRE I'd say this is a very prudent suggestion. I personally like the second approach best because IIUC it doesn't affect the schema. It might also be neat for Geronimo to have a stock GBean that compares the properties it gets passed against the runtime env and provides a clear error message and/or fails to start if they don't match. Applications/components with specific runtime reqs could optionally reference it in their plans. Just a thought... Best wishes, Paul On 3/1/06, John Sisson <[EMAIL PROTECTED]> wrote: It sounds like we could run into this issue in the future where a configuration (possibly provided by a third party) has a minimum JDK requirement. Would it make sense to have the minimum JDK requirements in the plan XML so we can gracefully skip loading configurations when the hosting VM does not meet the requirements? Another approach could be to specify configuration activation criteria (e.g. like Maven 2's activation element in the pom) so one could provide an assembly with some configurations for specific JDK levels or possibly for specific operating systems (e.g. if you have configurations that use JNI to provides access to particular O/S features) where the configurations only get started if they are running in the appropriate environment. Not high priority, but thought it might be worth discussing for the future.. John
[jira] Created: (GERONIMO-1677) geronimo-dependency-plugin deletion
geronimo-dependency-plugin deletion --- Key: GERONIMO-1677 URL: http://issues.apache.org/jira/browse/GERONIMO-1677 Project: Geronimo Type: Sub-task Reporter: 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-1676) Tomcat assembly get FileNotFoundException for geronimo.log during server initalization
[ http://issues.apache.org/jira/browse/GERONIMO-1676?page=all ] Joe Bohn updated GERONIMO-1676: --- Summary: Tomcat assembly get FileNotFoundException for geronimo.log during server initalization (was: Tomcat assembly get FileNotFoundException during server initalization) > Tomcat assembly get FileNotFoundException for geronimo.log during server > initalization > -- > > Key: GERONIMO-1676 > URL: http://issues.apache.org/jira/browse/GERONIMO-1676 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.x > Environment: Windows XP using trunk rev 382444 > Reporter: Joe Bohn > > I hit this problem with Tomcat on 2 different windows machines after getting > a new image from trunk today. It only happens in the tomcat assembly but > not in the jetty assembly. Here's the stack trace: > C:\geronimo\assemblies\j2ee-tomcat-server\target\geronimo-1.2-SNAPSHOT>java > -jar bin\server.jar > Booting Geronimo Kernel (in Java 1.4.2_08)... > log4j:ERROR setFile(null,true) call failed. > java.io.FileNotFoundException: \var\log\geronimo.log (The system cannot find > the path specified) > at java.io.FileOutputStream.openAppend(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:177) > at java.io.FileOutputStream.(FileOutputStream.java:102) > at org.apache.log4j.FileAppender.setFile(FileAppender.java:272) > at > org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:156) > at > org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151) > at > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:247) > at > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:123) > at > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:87) > at > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:645) > at > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:603) > at > org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:500) > at > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:406) > at > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:432) > at > org.apache.geronimo.system.logging.log4j.URLConfigurator.doConfigure(URLConfigurator.java:117) > at > org.apache.geronimo.system.logging.log4j.URLConfigurator.configure(URLConfigurator.java:44) > at > org.apache.geronimo.system.logging.log4j.Log4jService.reconfigure(Log4jService.java:518) > at > org.apache.geronimo.system.logging.log4j.Log4jService.doStart(Log4jService.java:561) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:520) > at > org.apache.geronimo.gbean.runtime.GBeanSingleReference.attemptFullStart(GBeanSingleReference.java:154) > at > org.apache.geronimo.gbean.runtime.GBeanSingleReference.targetAdded(GBeanSingleReference.java:127) > at > org.apache.geronimo.gbean.runtime.AbstractGBeanReference.addTarget(AbstractGBeanReference.java:242) > at > org.apache.geronimo.gbean.runtime.GBeanSingleReference$1.running(GBeanSingleReference.java:163) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:155) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:38) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:231) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:350) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > at > org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) > at > org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
[jira] Created: (GERONIMO-1676) Tomcat assembly get FileNotFoundException during server initalization
Tomcat assembly get FileNotFoundException during server initalization - Key: GERONIMO-1676 URL: http://issues.apache.org/jira/browse/GERONIMO-1676 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.x Environment: Windows XP using trunk rev 382444 Reporter: Joe Bohn I hit this problem with Tomcat on 2 different windows machines after getting a new image from trunk today. It only happens in the tomcat assembly but not in the jetty assembly. Here's the stack trace: C:\geronimo\assemblies\j2ee-tomcat-server\target\geronimo-1.2-SNAPSHOT>java -jar bin\server.jar Booting Geronimo Kernel (in Java 1.4.2_08)... log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: \var\log\geronimo.log (The system cannot find the path specified) at java.io.FileOutputStream.openAppend(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:177) at java.io.FileOutputStream.(FileOutputStream.java:102) at org.apache.log4j.FileAppender.setFile(FileAppender.java:272) at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:156) at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151) at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:247) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:123) at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:87) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:645) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:603) at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:500) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:406) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:432) at org.apache.geronimo.system.logging.log4j.URLConfigurator.doConfigure(URLConfigurator.java:117) at org.apache.geronimo.system.logging.log4j.URLConfigurator.configure(URLConfigurator.java:44) at org.apache.geronimo.system.logging.log4j.Log4jService.reconfigure(Log4jService.java:518) at org.apache.geronimo.system.logging.log4j.Log4jService.doStart(Log4jService.java:561) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:520) at org.apache.geronimo.gbean.runtime.GBeanSingleReference.attemptFullStart(GBeanSingleReference.java:154) at org.apache.geronimo.gbean.runtime.GBeanSingleReference.targetAdded(GBeanSingleReference.java:127) at org.apache.geronimo.gbean.runtime.AbstractGBeanReference.addTarget(AbstractGBeanReference.java:242) at org.apache.geronimo.gbean.runtime.GBeanSingleReference$1.running(GBeanSingleReference.java:163) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:155) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:38) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:231) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:350) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) at org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) at org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java
[jira] Updated: (GERONIMO-1675) Add NNTP transport to the javamail package.
[ http://issues.apache.org/jira/browse/GERONIMO-1675?page=all ] Rick McGuire updated GERONIMO-1675: --- Attachment: GERONIMO-1675.patch Applied to the javamail-transport module. > Add NNTP transport to the javamail package. > --- > > Key: GERONIMO-1675 > URL: http://issues.apache.org/jira/browse/GERONIMO-1675 > Project: Geronimo > Type: New Feature > Components: mail > Versions: 1.x > Reporter: Rick McGuire > Attachments: GERONIMO-1675.patch > > Add the capability of posting messages to NNTP servers using the javamail > API. This is a capability that the Sun version does not currently have. -- 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-1675) Add NNTP transport to the javamail package.
Add NNTP transport to the javamail package. Key: GERONIMO-1675 URL: http://issues.apache.org/jira/browse/GERONIMO-1675 Project: Geronimo Type: New Feature Components: mail Versions: 1.x Reporter: Rick McGuire Attachments: GERONIMO-1675.patch Add the capability of posting messages to NNTP servers using the javamail API. This is a capability that the Sun version does not currently have. -- 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-1674) Daytrader gets NullPointerException attempting to log in a user
Daytrader gets NullPointerException attempting to log in a user --- Key: GERONIMO-1674 URL: http://issues.apache.org/jira/browse/GERONIMO-1674 Project: Geronimo Type: Bug Components: sample apps Versions: 1.x Environment: Windows XP Reporter: Joe Bohn Daytrader gets the following NPE exception when attempting to signon: 13:47:05,510 ERROR [Log] Error: TradeDirect:login -- error logging in user java.lang.NullPointerException java.lang.NullPointerException at org.apache.geronimo.samples.daytrader.util.FinancialUtils.computeGainPercent(FinancialUtils.java:43) at org.apache.geronimo.samples.daytrader.MarketSummaryDataBean.(MarketSummaryDataBean.java:54) at org.apache.geronimo.samples.daytrader.direct.TradeDirect.getMarketSummary(TradeDirect.java:151) at org.apache.geronimo.samples.daytrader.TradeAction.getMarketSummary(TradeAction.java:99) at org.apache.jsp.marketSummary_jsp._jspService(org.apache.jsp.marketSummary_jsp:56) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:966) at org.apache.jsp.tradehome_jsp._jspService(org.apache.jsp.tradehome_jsp:282) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.requestDispatch(TradeServletAction.java:730) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doHome(TradeServletAction.java:319) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doLogin(TradeServletAction.java:357) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:132) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doPost(TradeAppServlet.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:92) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
[jira] Updated: (GERONIMO-1673) SMTPTransport is not performing byte-stuffing and newline canonicalization on message data.
[ http://issues.apache.org/jira/browse/GERONIMO-1673?page=all ] Rick McGuire updated GERONIMO-1673: --- Attachment: GERONIMO-1673.patch Applied to javamail-transport module. > SMTPTransport is not performing byte-stuffing and newline canonicalization on > message data. > --- > > Key: GERONIMO-1673 > URL: http://issues.apache.org/jira/browse/GERONIMO-1673 > Project: Geronimo > Type: Bug > Components: mail > Versions: 1.x > Reporter: Rick McGuire > Attachments: GERONIMO-1673.patch > > The MIME spec requires that all message line breaks be converted into proper > CRLF sequence (linebreak canonicalization) and that any period at the > beginning of a line be "byte-stuffed" (two periods written out instead of > one). The current SMTPTransport is just takes the message data as is. The > byte-stuffing is particularly important, since this prevents periods within > the message from being mistaken with the DATA command terminator string. > This fault can cause message truncation. -- 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-1673) SMTPTransport is not performing byte-stuffing and newline canonicalization on message data.
SMTPTransport is not performing byte-stuffing and newline canonicalization on message data. Key: GERONIMO-1673 URL: http://issues.apache.org/jira/browse/GERONIMO-1673 Project: Geronimo Type: Bug Components: mail Versions: 1.x Reporter: Rick McGuire Attachments: GERONIMO-1673.patch The MIME spec requires that all message line breaks be converted into proper CRLF sequence (linebreak canonicalization) and that any period at the beginning of a line be "byte-stuffed" (two periods written out instead of one). The current SMTPTransport is just takes the message data as is. The byte-stuffing is particularly important, since this prevents periods within the message from being mistaken with the DATA command terminator string. This fault can cause message truncation. -- 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-1672) Migrate security module to M2
[ http://issues.apache.org/jira/browse/GERONIMO-1672?page=all ] Anita Kulshreshtha reassigned GERONIMO-1672: Assign To: Anita Kulshreshtha This requires interceptor module. > 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 > -- 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: Migrating to maven 2
On 3/2/06, David Jencks <[EMAIL PROTECTED]> wrote: > > On Mar 2, 2006, at 10:00 AM, Henri Yandell wrote: > > > On 3/2/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > >> Anyone know if there's a way to get Maven to dump the transitive > >> build > >> order from the project.xmls? That would indicate the order to fix > >> in I > >> think. > > > > > > Please ignore the idiot. Maven 1 does not have transitive builds :) > > ?? > > if you run maven -o new1 I think you will find the order you want on > the console kill it before it scrolls into oblivion. Rock, so we should reorder the wiki page to match that. I'll go ahead and see how that goes in a few moments. Thanks David, Hen
Re: Migrating to maven 2
On Mar 2, 2006, at 10:00 AM, Henri Yandell wrote: On 3/2/06, Henri Yandell <[EMAIL PROTECTED]> wrote: Anyone know if there's a way to get Maven to dump the transitive build order from the project.xmls? That would indicate the order to fix in I think. Please ignore the idiot. Maven 1 does not have transitive builds :) ?? if you run maven -o new1 I think you will find the order you want on the console kill it before it scrolls into oblivion. thanks david jencks Hen
Re: Migrating to maven 2
On 3/2/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > Anyone know if there's a way to get Maven to dump the transitive build > order from the project.xmls? That would indicate the order to fix in I > think. Please ignore the idiot. Maven 1 does not have transitive builds :) Hen
Re: Migrating to maven 2
On 3/2/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > Hmm.. somewhere up in this thread, someone had mentioned that we > should do this as a bottoms-up approach where we migrate the ones > without any deps (call it base modules) first and then work up the > chain. > > That will impose a sequential order on the migration effort and may > also possibly hold it up. If we are to randomly attack it, then maybe > we have to use the maven-install-plugin to install the required m1 dep > jars in m2 local repo. But atleast now, more and more modules can be > converted and the code checked in. > > If we used the latter approach, then we'll have to wait till the base > modules have migrated before turning on the top down build. Currently, > the maven.xml builds only the kernel module in the m2 format anyways. > > What do you think ? Yes :) It seems like this is what's happening anyway? It'd be hard to do it bottom down unless it was all happening in one person's head. So I've leapt into -axis, simply because Axis is a project I'm interested in so why not :) This leads me to looking at webservices which seems to be missing interceptor at the moment, so then I end up in there. Eventually I'll be sending in patches for the base level stuff, and then moving back to axis. We need to get something automated setup - the interceptor problem in webservices is because of on-going development, yet we have it marked as a Green-good on the wiki page. Anyone know if there's a way to get Maven to dump the transitive build order from the project.xmls? That would indicate the order to fix in I think. Hen
[jira] Commented: (GERONIMO-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
[
http://issues.apache.org/jira/browse/GERONIMO-1669?page=comments#action_12368548
]
Vamsavardhana Reddy commented on GERONIMO-1669:
---
Transport.send(msg) works properly now. Server built from revision 382452.
> javamail Transport.send() is not issuing connect() on the transport before
> sending the message.
> ---
>
> Key: GERONIMO-1669
> URL: http://issues.apache.org/jira/browse/GERONIMO-1669
> Project: Geronimo
> Type: Bug
> Components: mail
> Versions: 1.x
> Reporter: Rick McGuire
> Assignee: Jacek Laskowski
> Fix For: 1.1
> Attachments: GERONIMO-1669.patch
>
> This was reported on the geronimo user list (problem report attached below).
> The error is occuring because the Transport.send() code is failing to
> surround the sendMessage() call with connect() and close() calls on the
> transport, resulting in the connection failure. Additionally, this code is
> not properly merging send failures for multiple transports into a single
> SendFailedException with proper reporting of which addresses the message was
> not sent to.
> Hi Alex,
> I am trying to send mail from a servlet. Here is my geronimo-web.xml:
>
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
> xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> configId="MailWebApp/MailWebApp">
>
> geronimo/geronimo-mail/1.2-SNAPSHOT
>
>
> geronimo/geronimo-javamail-transport/1.2-SNAPSHOT
>
> /MailWebApp
> false
>
> mail/MailSession
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
>
>
>
>
> smtp
> 9.182.150.56
> false
>
> mail.debug=true
> [EMAIL PROTECTED]
> mail.smtp.port=25
>
>
> Here are the imports and the doGet() method in my servlet.
> import javax.mail.Session;
> import javax.mail.Transport;
> import javax.mail.Message.RecipientType;
> import javax.mail.internet.InternetAddress;
> import javax.mail.internet.MimeMessage;
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>
> response.setContentType("text/plain");
>
> PrintWriter out = response.getWriter();
>
> try {
> InitialContext ic = new InitialContext();
>
> Session mailSession = (Session)
> ic.lookup("java:comp/env/mail/MailSession");
> mailSession.setDebug(true);
> mailSession.setDebugOut(System.err);
> out.println("session = "+mailSession);
>
> MimeMessage msg = new MimeMessage(mailSession);
>
> msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
> InternetAddress("[EMAIL PROTECTED]")});
>
> msg.setSubject("Mail sent by MailerServlet");
>
> msg.setText("Hello");
>
> msg.setFrom(InternetAddress.getLocalAddress(mailSession));
>
> Transport.send(msg);
> } catch (Exception e) {
> e.printStackTrace(out);
> }
> }
> When I access the servlet, I am getting the following Exception.
> java.lang.IllegalStateException: Not connected
> at
> org.apache.geronimo.javamail.transport.smtp.SMTPTransport.sendMessage(SMTPTransport.java:356)
> at javax.mail.Transport.send(Transport.java:80)
> at javax.mail.Transport.send
> (Transport.java:46)
> at mailwebapp.MailerServlet.doGet(MailerServlet.java:64)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
> at
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:273)
> at
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at
> org.apache.catalina.valves.Er
RE: [wtp-dev] Proposal for Merging Server Runtime and Server Instance
With this change, could you go over a user case where user would develop/test his J2EE application locally first then deploy it to the remote production server? I could not think of how to tie the runtime and server together in remote deployment environment. Thanks, Lin -Original Message- From: Sachin Patel [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 7:34 PM To: dev@geronimo.apache.org Subject: Re: [wtp-dev] Proposal for Merging Server Runtime and Server Instance So hopefully this will make sense... :) In the two proposal notes I sent, the discussion is around the 3 concepts in WTP, "runtimes", "servers", and "facets" and what we can do to improve the definition, design and interaction between the frameworks that these concepts represent. So for those not familiar with WTP, let me start by describing these concepts from a "users perspective". RUNTIMES & SERVERS So currently WTP has a notion of defining a "runtime" and defining a "server". So for a user wanting to create a j2ee app using WTP and deploy it to geronimo the user must perform currently two distinct tasks. (1) Is to define a Geronimo runtime using a wizard which asks the location of the runtime which you would point to a geronimo installation. During project creation you would choose this newly defined runtime and what this essentially does is configures the project to add a JRE and a "runtime classpath container" which contains all of the geronimo spec jars + other G jars. This means that this project is "targeted" to be deployed to geronimo. Now in order to deploy that application, the user currently has to perform a second task, and that is to define and point to the actual server instance. You may immediatly ask yourself, didn't I just do that by defining the runtime? This is currently confusing to users, as the note below indicates. Not only are the definition of the terms confusing in discussions as many times there are used interchangably, but from a users perspective they need to manage in the UI both the list of servers and runtimes and the mapping between the two. And most of all what is confusing in the above case, both the runtime and the server are pointing to the same thing! This usability needs to change. So one of the proposals is for these two to be merged togather, with all server instances being runtimes, but not vise versa. Runtimes may or may not represent a server instance. (Multiple server instances may have unique configuration/launching data in distinct location but share the same runtime jars. For example WebSphere has a concept of profiles). So with that re-read below and hopefully the note will make more sense. FACETS -- Facets are basically a unit of function that can be applied and removed to a given WTP project. For example, if a user is wanting to create a "Web Project" the "web facet" is selected and this creates the project directory structure specific for a web project, web.xml, etc So how do facets relate to geronimo runtimes and servers? Since G is headed toward a model where a user can produce a custom server image (i.e web container only, no j2ee, etc...) each distribution may be different. So after defining a runtime by pointing to this installation, some facets may or not be applicable to add on a project. So from a tooling perspective we should be able to ask...Given this "runtime" what kind of capabilties do I have? What kind of projects can I create? Now the second use case is that a user may not be interested in deploying his app yet and only concerned is developing a project that would be supported geronimo. So they may or may not have a local geronimo install image. So with our integration and use of maven, we should be able to take a more appcentric approach in the tools as well. So the user should be able to simply choose the ejb project creation wizard, select geronimo, and we should be able to dynamically generate the minimum runtime for that project by pulling in the necessary jars from their local install or from a maven repo. I hope that helps. - sachin On Mar 1, 2006, at 5:35 PM, Dain Sundstrom wrote: > Sachin, can you translate this from eclipse speak to geronimo speak? > > -dain > > On Mar 1, 2006, at 1:23 PM, Sachin Patel wrote: > >> Please respond with any comments or concerns you have with this >> second proposal as it will have a direct affect on G tooling. >> >> - sachin >> >> >> >> Begin forwarded message: >> >>> From: "Konstantin Komissarchik" <[EMAIL PROTECTED]> >>> Date: March 1, 2006 4:02:33 PM EST >>> To: "General discussion of project-wide or architectural issues." >>> >>> Subject: [wtp-dev] Proposal for Merging Server Runtime and Server >>> Instance >>> Reply-To: "General discussion of project-wide or architectural >>> issues." >>> >>> Currently the server tools framework has a separate
Re: Migrating to maven 2
Hmm.. somewhere up in this thread, someone had mentioned that we should do this as a bottoms-up approach where we migrate the ones without any deps (call it base modules) first and then work up the chain. That will impose a sequential order on the migration effort and may also possibly hold it up. If we are to randomly attack it, then maybe we have to use the maven-install-plugin to install the required m1 dep jars in m2 local repo. But atleast now, more and more modules can be converted and the code checked in. If we used the latter approach, then we'll have to wait till the base modules have migrated before turning on the top down build. Currently, the maven.xml builds only the kernel module in the m2 format anyways. What do you think ? Cheers Prasad On 3/2/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > Jacek, > maven1 build puts jars in > .../.maven/repository/o/a/g/jars and poms in poms dir. > It would be nice if they could be written to > /.m2/repository/org/apache/geronimo in maven2 > directory format. This would allow us to build any > single module using mvn. The jars for the modules that > have not been migrated will be available at .m2. > So the process for migration of a-module will be : > 1. maven new (or whatever) (after a checkout) > 2. mvn install > 3. cd modules/a-module > 4. mvn install > > Thanks > Anita > > --- Jacek Laskowski <[EMAIL PROTECTED]> wrote: > > > 2006/3/2, anita kulshreshtha <[EMAIL PROTECTED]>: > > > Prasad, > > > Thanks! The version no. for > > > geronimo-javamail_1.3.1_spec jar is 1.1-SNAPSHOT > > in > > > maven1 build and 1.2-SNAPSHOT in maven2 build. > > There > > > is a working pom.xml for naming-builder but it is > > not > > > in the list in the parent pom.xml (rev > > > 382066). > > > > Thanks Anita! The solution's been checked in as > > revision 382362. I > > meant to do it yesterday, but had no much time. > > > > > 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: [jira] Created: (GERONIMO-1672) Migrate security module to M2
Only security module is processing xdocs in maven 1 build! How is it being handled in M2? Thanks Anita --- "Anita Kulshreshtha (JIRA)" wrote: > 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 > Fix For: 1.x > > > > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of > the administrators: > > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: >http://www.atlassian.com/software/jira > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Migrating to maven 2
Having the two wikis is confusing; but definitely +1 on recording the state of the migration in a wiki. Hen On 3/2/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > Jacek, until we all agree on a tool that will capture the status, I'll > try my best to keep the confluence wiki updated. > > It'd be nice if others could update the wiki too with their status and > issues. The confluence wiki is very easy to use. It's just like > editing a word document.
[jira] Created: (GERONIMO-1672) Migrate security module to M2
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 Fix For: 1.x -- 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: Migrating to maven 2
Jacek, until we all agree on a tool that will capture the status, I'll try my best to keep the confluence wiki updated. It'd be nice if others could update the wiki too with their status and issues. The confluence wiki is very easy to use. It's just like editing a word document. Cheers Prasad On 3/2/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > 2006/3/2, Prasad Kashyap <[EMAIL PROTECTED]>: > > > However, a lot of important decisions and information gets drowned in > > the chatter here. So the wiki can be used to get a snapshot summary & > > status of the work in progress. This will be useful for folks who are > > not really following this thread but yet are interested/stakeholders > > in the conversion effort. > > Sure. I remember Dain who asked about it, but will you remember to > update Wiki and JIRA tasks and keeping updated the dev mailing list? > Well, let's try it out and see how it goes. I'm however very concerned > with the overwhelming number of available tools that are often > overused. I think it deserves a separate thread when we should decide > how our documentation efforts should be managed. > > > Prasad > > Jacek > > -- > Jacek Laskowski > http://www.laskowski.org.pl >
Re: Available tools and their use
Hi All, following the thread I found really convenient to have a snapshot with the current status in confluence, all the info is in one page and there are links to specific JIRAs. I don't think we can have the info displayed in the same way directly with JIRA. As for the web site, I think it will be easier to update confluence than the geronimo web site. Although we should add some pointers in the web site to where this info is held. Cheers! Hernan Jacek Laskowski wrote: Hi, The question struck me while discussing how to keep the progress of the M2 migration. I think I need some guidance. We've got lots of tools to use at/outside ASF to describe how the project development goes. The wiki, the website, the confluence-based website, JIRA, mailing lists occasionally seem to be too much for me to cope with. I wonder how we should use them so all will benefit/pleased from/with their use. How are your experiences/thoughts about it? Before I write how I see it I'd like to read others' comments on it. Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Commented: (GERONIMO-1645) tomcat module migration to Maven2
[ http://issues.apache.org/jira/browse/GERONIMO-1645?page=comments#action_12368512 ] Jeff Genender commented on GERONIMO-1645: - Please use commons modeler 1.1, not M1. The poms must patch what we have there today...we cannot downgrade. > tomcat module migration to Maven2 > - > > Key: GERONIMO-1645 > URL: http://issues.apache.org/jira/browse/GERONIMO-1645 > Project: Geronimo > Type: Sub-task > Components: Tomcat > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Attachments: pom.patch, pom.xml, pom.xml, pom.xml, pom.xml > > It's a task to help keep track of the progress of the tomcat 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: Migrating to maven 2
These are the results of mvn install today(rev 382374, openejb rev 2526) 1. test failure in system 2. test failure in j2ee 3. error loading schema in j2ee-schema 4. test filure in derby (this was ok yesterday) --- T E S T S --- [surefire] Running org.apache.geronimo.derby.DerbySystemGBeanTest [surefire] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 8.203 sec FAILURE !! Thanks Anita --- anita kulshreshtha <[EMAIL PROTECTED]> wrote: > Jacek, > maven1 build puts jars in > .../.maven/repository/o/a/g/jars and poms in poms > dir. > It would be nice if they could be written to > /.m2/repository/org/apache/geronimo in maven2 > directory format. This would allow us to build any > single module using mvn. The jars for the modules > that > have not been migrated will be available at .m2. > So the process for migration of a-module will be : > 1. maven new (or whatever) (after a checkout) > 2. mvn install > 3. cd modules/a-module > 4. mvn install > > Thanks > Anita > > --- Jacek Laskowski <[EMAIL PROTECTED]> wrote: > > > 2006/3/2, anita kulshreshtha > <[EMAIL PROTECTED]>: > > > Prasad, > > > Thanks! The version no. for > > > geronimo-javamail_1.3.1_spec jar is 1.1-SNAPSHOT > > in > > > maven1 build and 1.2-SNAPSHOT in maven2 build. > > There > > > is a working pom.xml for naming-builder but it > is > > not > > > in the list in the parent pom.xml (rev > > > 382066). > > > > Thanks Anita! The solution's been checked in as > > revision 382362. I > > meant to do it yesterday, but had no much time. > > > > > 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 > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Updated: (GERONIMO-1645) tomcat module migration to Maven2
[ http://issues.apache.org/jira/browse/GERONIMO-1645?page=all ] Anita Kulshreshtha updated GERONIMO-1645: - Attachment: pom.patch This is pom.xml for tomcat module. It uses commons-modeler-1.1M1.jar (not 1.1) > tomcat module migration to Maven2 > - > > Key: GERONIMO-1645 > URL: http://issues.apache.org/jira/browse/GERONIMO-1645 > Project: Geronimo > Type: Sub-task > Components: Tomcat > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Attachments: pom.patch, pom.xml, pom.xml, pom.xml, pom.xml > > It's a task to help keep track of the progress of the tomcat 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: Migrating to maven 2
Jacek, maven1 build puts jars in .../.maven/repository/o/a/g/jars and poms in poms dir. It would be nice if they could be written to /.m2/repository/org/apache/geronimo in maven2 directory format. This would allow us to build any single module using mvn. The jars for the modules that have not been migrated will be available at .m2. So the process for migration of a-module will be : 1. maven new (or whatever) (after a checkout) 2. mvn install 3. cd modules/a-module 4. mvn install Thanks Anita --- Jacek Laskowski <[EMAIL PROTECTED]> wrote: > 2006/3/2, anita kulshreshtha <[EMAIL PROTECTED]>: > > Prasad, > > Thanks! The version no. for > > geronimo-javamail_1.3.1_spec jar is 1.1-SNAPSHOT > in > > maven1 build and 1.2-SNAPSHOT in maven2 build. > There > > is a working pom.xml for naming-builder but it is > not > > in the list in the parent pom.xml (rev > > 382066). > > Thanks Anita! The solution's been checked in as > revision 382362. I > meant to do it yesterday, but had no much time. > > > 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
Available tools and their use
Hi, The question struck me while discussing how to keep the progress of the M2 migration. I think I need some guidance. We've got lots of tools to use at/outside ASF to describe how the project development goes. The wiki, the website, the confluence-based website, JIRA, mailing lists occasionally seem to be too much for me to cope with. I wonder how we should use them so all will benefit/pleased from/with their use. How are your experiences/thoughts about it? Before I write how I see it I'd like to read others' comments on it. Jacek -- Jacek Laskowski http://www.laskowski.org.pl
JIRA and svn changes - how to tie it up?
Hi, I've seen a couple of times that some JIRA issues where accompanied with svn changes. How can it be done? Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Resolved: (GERONIMO-1670) SMTPTransport not throwing correct exception for message send failures.
[ http://issues.apache.org/jira/browse/GERONIMO-1670?page=all ] Jacek Laskowski resolved GERONIMO-1670: --- Fix Version: 1.x Resolution: Fixed Assign To: Jacek Laskowski $ svn ci -m 'GERONIMO-1670: SMTPTransport not throwing correct exception for message send failures' . Sending javamail-transport/src/java/org/apache/geronimo/javamail/transport/smtp/SMTPTransport.java Transmitting file data . Committed revision 382389. Thanks Rick! > SMTPTransport not throwing correct exception for message send failures. > --- > > Key: GERONIMO-1670 > URL: http://issues.apache.org/jira/browse/GERONIMO-1670 > Project: Geronimo > Type: Bug > Components: mail > Versions: 1.x > Reporter: Rick McGuire > Assignee: Jacek Laskowski > Priority: Minor > Fix For: 1.x > Attachments: GERONIMO-1670.patch > > The SMTPTransport is throwing a simple MessagingException for failures due to > the SMTP DATA command. This sort of failure should be throwing a > SendFailedException with the address list information indicating that this > was a failure to all of the valid addresses (and also listing the invalid > addresses). > This was discovered while fixing 1669. -- 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] Resolved: (GERONIMO-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
[ http://issues.apache.org/jira/browse/GERONIMO-1669?page=all ]
Jacek Laskowski resolved GERONIMO-1669:
---
Fix Version: 1.1
Resolution: Fixed
Assign To: Jacek Laskowski
$ svn ci -m 'GERONIMO-1669: javamail Transport.send() is not issuing connect()
on the transport before sending the message' .
Sendinggeronimo-spec-javamail/src/main/java/javax/mail/Transport.java
Transmitting file data .
Committed revision 382388.
Thanks Rick!
> javamail Transport.send() is not issuing connect() on the transport before
> sending the message.
> ---
>
> Key: GERONIMO-1669
> URL: http://issues.apache.org/jira/browse/GERONIMO-1669
> Project: Geronimo
> Type: Bug
> Components: mail
> Versions: 1.x
> Reporter: Rick McGuire
> Assignee: Jacek Laskowski
> Fix For: 1.1
> Attachments: GERONIMO-1669.patch
>
> This was reported on the geronimo user list (problem report attached below).
> The error is occuring because the Transport.send() code is failing to
> surround the sendMessage() call with connect() and close() calls on the
> transport, resulting in the connection failure. Additionally, this code is
> not properly merging send failures for multiple transports into a single
> SendFailedException with proper reporting of which addresses the message was
> not sent to.
> Hi Alex,
> I am trying to send mail from a servlet. Here is my geronimo-web.xml:
>
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
> xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> configId="MailWebApp/MailWebApp">
>
> geronimo/geronimo-mail/1.2-SNAPSHOT
>
>
> geronimo/geronimo-javamail-transport/1.2-SNAPSHOT
>
> /MailWebApp
> false
>
> mail/MailSession
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
>
>
>
>
> smtp
> 9.182.150.56
> false
>
> mail.debug=true
> [EMAIL PROTECTED]
> mail.smtp.port=25
>
>
> Here are the imports and the doGet() method in my servlet.
> import javax.mail.Session;
> import javax.mail.Transport;
> import javax.mail.Message.RecipientType;
> import javax.mail.internet.InternetAddress;
> import javax.mail.internet.MimeMessage;
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>
> response.setContentType("text/plain");
>
> PrintWriter out = response.getWriter();
>
> try {
> InitialContext ic = new InitialContext();
>
> Session mailSession = (Session)
> ic.lookup("java:comp/env/mail/MailSession");
> mailSession.setDebug(true);
> mailSession.setDebugOut(System.err);
> out.println("session = "+mailSession);
>
> MimeMessage msg = new MimeMessage(mailSession);
>
> msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
> InternetAddress("[EMAIL PROTECTED]")});
>
> msg.setSubject("Mail sent by MailerServlet");
>
> msg.setText("Hello");
>
> msg.setFrom(InternetAddress.getLocalAddress(mailSession));
>
> Transport.send(msg);
> } catch (Exception e) {
> e.printStackTrace(out);
> }
> }
> When I access the servlet, I am getting the following Exception.
> java.lang.IllegalStateException: Not connected
> at
> org.apache.geronimo.javamail.transport.smtp.SMTPTransport.sendMessage(SMTPTransport.java:356)
> at javax.mail.Transport.send(Transport.java:80)
> at javax.mail.Transport.send
> (Transport.java:46)
> at mailwebapp.MailerServlet.doGet(MailerServlet.java:64)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
> at
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:273)
> a
[jira] Resolved: (GERONIMO-1671) InternetAddress.getLocalAddress() does not properly implement the local address resolution path.
[ http://issues.apache.org/jira/browse/GERONIMO-1671?page=all ] Jacek Laskowski resolved GERONIMO-1671: --- Fix Version: 1.1 Resolution: Fixed Assign To: Jacek Laskowski $ svn ci . Sending geronimo-spec-javamail/src/main/java/javax/mail/internet/InternetAddress.java Sending geronimo-spec-javamail/src/test/java/javax/mail/internet/InternetAddressTest.java Transmitting file data .. Committed revision 382387. Thanks Rick! > InternetAddress.getLocalAddress() does not properly implement the local > address resolution path. > > > Key: GERONIMO-1671 > URL: http://issues.apache.org/jira/browse/GERONIMO-1671 > Project: Geronimo > Type: Bug > Components: mail > Versions: 1.x > Reporter: Rick McGuire > Assignee: Jacek Laskowski > Priority: Minor > Fix For: 1.1 > Attachments: GERONIMO-1671.patch > > The InternetAddress.getLocalAddress() method is not properly implementing the > full address resolution path for all paths. In particular, if a session is > provided, it does not fall back to using the "user.name" system property as > the last default value. -- 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: Migrating to maven 2
2006/3/2, Prasad Kashyap <[EMAIL PROTECTED]>: > However, a lot of important decisions and information gets drowned in > the chatter here. So the wiki can be used to get a snapshot summary & > status of the work in progress. This will be useful for folks who are > not really following this thread but yet are interested/stakeholders > in the conversion effort. Sure. I remember Dain who asked about it, but will you remember to update Wiki and JIRA tasks and keeping updated the dev mailing list? Well, let's try it out and see how it goes. I'm however very concerned with the overwhelming number of available tools that are often overused. I think it deserves a separate thread when we should decide how our documentation efforts should be managed. > Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Updated: (GERONIMO-1671) InternetAddress.getLocalAddress() does not properly implement the local address resolution path.
[ http://issues.apache.org/jira/browse/GERONIMO-1671?page=all ] Rick McGuire updated GERONIMO-1671: --- Attachment: GERONIMO-1671.patch Patch for the code and some additional unit tests to validate the resolution path. > InternetAddress.getLocalAddress() does not properly implement the local > address resolution path. > > > Key: GERONIMO-1671 > URL: http://issues.apache.org/jira/browse/GERONIMO-1671 > Project: Geronimo > Type: Bug > Components: mail > Versions: 1.x > Reporter: Rick McGuire > Priority: Minor > Attachments: GERONIMO-1671.patch > > The InternetAddress.getLocalAddress() method is not properly implementing the > full address resolution path for all paths. In particular, if a session is > provided, it does not fall back to using the "user.name" system property as > the last default value. -- 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-1671) InternetAddress.getLocalAddress() does not properly implement the local address resolution path.
InternetAddress.getLocalAddress() does not properly implement the local address resolution path. - Key: GERONIMO-1671 URL: http://issues.apache.org/jira/browse/GERONIMO-1671 Project: Geronimo Type: Bug Components: mail Versions: 1.x Reporter: Rick McGuire Priority: Minor Attachments: GERONIMO-1671.patch The InternetAddress.getLocalAddress() method is not properly implementing the full address resolution path for all paths. In particular, if a session is provided, it does not fall back to using the "user.name" system property as the last default value. -- 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: Migrating to maven 2
Jacek, I couldn't agree more. That is exactly what we should be doing. The devlist is a more happening place. So we should continue with all the discussions here. However, a lot of important decisions and information gets drowned in the chatter here. So the wiki can be used to get a snapshot summary & status of the work in progress. This will be useful for folks who are not really following this thread but yet are interested/stakeholders in the conversion effort. Cheers Prasad On 3/2/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > 2006/3/1, Prasad Kashyap <[EMAIL PROTECTED]>: > > Dain, your wish has been granted. Here is a humble beginning > > > > http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Migration+to+Maven2 > > Great work, Prasad! It's a pleasure to work with you and *try* to keep > your pace ;) > > But...why do we get used to use Wiki? Wouldn't it be better off if we > talked it over here, in the dev mailing list, and put it in the JIRA > task, afterwards? I think it's much better from historical perspective > when all changes are easily found in the archive(s). > > > Prasad. > > Jacek > > -- > Jacek Laskowski > http://www.laskowski.org.pl >
Re: svn commit: r382374 - in /geronimo/devtools/eclipse-plugin/trunk/maven-plugins/maven-emf-plugin: ./ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/emf/ src/ma
good catch, thx
- sachin
On Mar 2, 2006, at 8:19 AM, Jacek Laskowski wrote:
2006/3/2, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
+ * @goal xsd2Java
I think it'd be much easier to type/remember when the goal name is
xsd2java
+ */
+public class XSDImporterMojo extends AbstractMojo {
Jacek
--
Jacek Laskowski
http://www.laskowski.org.pl
Re: svn commit: r382374 - in /geronimo/devtools/eclipse-plugin/trunk/maven-plugins/maven-emf-plugin: ./ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/emf/ src/ma
2006/3/2, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> + * @goal xsd2Java
I think it'd be much easier to type/remember when the goal name is xsd2java
> + */
> +public class XSDImporterMojo extends AbstractMojo {
Jacek
--
Jacek Laskowski
http://www.laskowski.org.pl
[jira] Commented: (GERONIMO-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
[
http://issues.apache.org/jira/browse/GERONIMO-1669?page=comments#action_12368489
]
Rick McGuire commented on GERONIMO-1669:
Ah, sorry, I didn't read your earlier comment closely enough. Yes, all of the
module tests pass for me, but I'm not sure I can explain why it is working for
me and not for you. InternetAddress().getLocalAddress() depends on a number of
session/system properties being set to resolve the address. For some reason,
these are getting set properly for me automatically, but not for you. Bruce
Snyder also has not had a problem with this. Here is a short patch to the
MimeMessageTest module to explicitly configure some of the properties to remove
the system setup dependencies to the test.
Index: src/test/java/javax/mail/internet/MimeMessageTest.java
===
--- src/test/java/javax/mail/internet/MimeMessageTest.java (revision
381685)
+++ src/test/java/javax/mail/internet/MimeMessageTest.java (working copy)
@@ -377,7 +377,9 @@
myMap.addMailcap("text/plain;;x-java-content-handler=" +
MimeMultipartTest.DummyTextHandler.class.getName());
myMap.addMailcap("multipart/*;;x-java-content-handler=" +
MimeMultipartTest.DummyMultipartHandler.class.getName());
CommandMap.setDefaultCommandMap(myMap);
-session = Session.getDefaultInstance(new Properties());
+Properties props = new Properties();
+props.put("mail.from", "[EMAIL PROTECTED]");
+session = Session.getDefaultInstance(props);
}
protected void tearDown() throws Exception {
> javamail Transport.send() is not issuing connect() on the transport before
> sending the message.
> ---
>
> Key: GERONIMO-1669
> URL: http://issues.apache.org/jira/browse/GERONIMO-1669
> Project: Geronimo
> Type: Bug
> Components: mail
> Versions: 1.x
> Reporter: Rick McGuire
> Attachments: GERONIMO-1669.patch
>
> This was reported on the geronimo user list (problem report attached below).
> The error is occuring because the Transport.send() code is failing to
> surround the sendMessage() call with connect() and close() calls on the
> transport, resulting in the connection failure. Additionally, this code is
> not properly merging send failures for multiple transports into a single
> SendFailedException with proper reporting of which addresses the message was
> not sent to.
> Hi Alex,
> I am trying to send mail from a servlet. Here is my geronimo-web.xml:
>
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
> xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> configId="MailWebApp/MailWebApp">
>
> geronimo/geronimo-mail/1.2-SNAPSHOT
>
>
> geronimo/geronimo-javamail-transport/1.2-SNAPSHOT
>
> /MailWebApp
> false
>
> mail/MailSession
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
>
>
>
>
> smtp
> 9.182.150.56
> false
>
> mail.debug=true
> [EMAIL PROTECTED]
> mail.smtp.port=25
>
>
> Here are the imports and the doGet() method in my servlet.
> import javax.mail.Session;
> import javax.mail.Transport;
> import javax.mail.Message.RecipientType;
> import javax.mail.internet.InternetAddress;
> import javax.mail.internet.MimeMessage;
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>
> response.setContentType("text/plain");
>
> PrintWriter out = response.getWriter();
>
> try {
> InitialContext ic = new InitialContext();
>
> Session mailSession = (Session)
> ic.lookup("java:comp/env/mail/MailSession");
> mailSession.setDebug(true);
> mailSession.setDebugOut(System.err);
> out.println("session = "+mailSession);
>
> MimeMessage msg = new MimeMessage(mailSession);
>
> msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
> InternetAddress("[EMAIL PROTECTED]")});
>
> msg.setSubject("Mail sent by MailerServlet");
>
> msg.setText("Hello");
>
> msg.setFrom(InternetAddress.getLocalAddress(mailSession));
>
> Transport.send(msg);
> } catch (Exception e) {
> e.printStackTrace(out);
> }
> }
> When I access the servlet, I am getting the following Exception.
> java.lang.Ille
Re: heads-up: Servlet-2.5 & jetty 6 branch?
2006/3/2, Greg Wilkins <[EMAIL PROTECTED]>: > everybody OK with this? +1 > I'd like to start this soonish, although I'm tempted to wait > for maven2 to be working. You're not the only one who awaits it working ;) Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Multiple servers sharing the same repo and config store
Thanks for the suggestion. This has been implemented. Gianny John Sisson wrote: Gianny, I think we should change the org.apache.geronimo.base.dir property to be org.apache.geronimo.home.dir so it is consistent in meaning with Tomcat's usage of the terms home and base to avoid confusion. In Tomcat: home = the installation directory base = the base directory used for resolving dynamic portions of the Tomcat installation (defaults to home if not set) John Gianny Damour wrote: Hi, This change adds the ability to start multiple server instances against the same bin, config-store, deploy, lib, repository and shema folders of a Geronimo installation. An additional instance can be set-up by copying the var folder to the directory where you want to create a new instance. Then, from the new server directory, you can start the new instance like this: java -Dorg.apache.geronimo.base.dir= -Dorg.apache.geronimo.server.dir= -jar /bin/server.jar * org.apache.geronimo.base.dir is the full path of the directory where Geronimo has been installed, i.e. it is the directory containing the config-store and repository to be shared; and * org.apache.geronimo.server.dir is the full path of the directory where the new instance has been set-up. This is in this directory that the instance specific working files are created, i.e. the stuff in var. Note that the value of this property can be either an absolute or relative directory. If a relative directory is specified, then it is resolved based on the Geronimo installation directory. If you are happy to start a new instance under the same Geronimo installation directory, then you can create a new nested folder and copy var into it. Then, from the Geronimo installation directory, you can start this new instance like this: java -Dorg.apache.geronimo.server.name= -jar bin/server.jar * org.apache.geronimo.server.name is the name of the nested folder. This has a similar effect than starting with org.apache.geronimo.server.dir set to the relative path of the nested folder. Thanks, Gianny Dave Colasurdo wrote: Can you please elaborate a bit more on what exactly this provides? Can I now have two separate instances each with their own unique applications/configurations/logs (i.e. config-store, deploy and var directories) sharing the same geronimo installation binaries (i.e. bin, lib and repository directories)? If so, how do we create the additional instances? I assume the binary distribution creates the the first instance during the build and that users need to create the additional instances manually for now.. Thanks -Dave- Gianny Damour wrote: Hi, The second solution has been implemented. When starting G, it is now possible to specify one of these two system properties: * org.apache.geronimo.server.name: name of the server to be started. If "server1" is specified, then G will use the directory /server1; or * org.apache.geronimo.server.dir: directory of the server to be started. This can be either a relative or an absolute path. For instance, if "./server1" is specified, then G will use the directory /server1. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny
[jira] Commented: (GERONIMO-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
[
http://issues.apache.org/jira/browse/GERONIMO-1669?page=comments#action_12368486
]
Jacek Laskowski commented on GERONIMO-1669:
---
You're right, but how can I apply the patch if the module tests fail? I had a
glimpse of what's going on in the code *before* I commented the issue and
couldn't find out how it had worked before. So, I was wondering how you tested
your change? I think it's important to fix the code (which I'm not very
familiar with) *before* applying any patches if they're irrelevant or don't
bring us closer to fix it.
> javamail Transport.send() is not issuing connect() on the transport before
> sending the message.
> ---
>
> Key: GERONIMO-1669
> URL: http://issues.apache.org/jira/browse/GERONIMO-1669
> Project: Geronimo
> Type: Bug
> Components: mail
> Versions: 1.x
> Reporter: Rick McGuire
> Attachments: GERONIMO-1669.patch
>
> This was reported on the geronimo user list (problem report attached below).
> The error is occuring because the Transport.send() code is failing to
> surround the sendMessage() call with connect() and close() calls on the
> transport, resulting in the connection failure. Additionally, this code is
> not properly merging send failures for multiple transports into a single
> SendFailedException with proper reporting of which addresses the message was
> not sent to.
> Hi Alex,
> I am trying to send mail from a servlet. Here is my geronimo-web.xml:
>
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
> xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> configId="MailWebApp/MailWebApp">
>
> geronimo/geronimo-mail/1.2-SNAPSHOT
>
>
> geronimo/geronimo-javamail-transport/1.2-SNAPSHOT
>
> /MailWebApp
> false
>
> mail/MailSession
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
>
>
>
>
> smtp
> 9.182.150.56
> false
>
> mail.debug=true
> [EMAIL PROTECTED]
> mail.smtp.port=25
>
>
> Here are the imports and the doGet() method in my servlet.
> import javax.mail.Session;
> import javax.mail.Transport;
> import javax.mail.Message.RecipientType;
> import javax.mail.internet.InternetAddress;
> import javax.mail.internet.MimeMessage;
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>
> response.setContentType("text/plain");
>
> PrintWriter out = response.getWriter();
>
> try {
> InitialContext ic = new InitialContext();
>
> Session mailSession = (Session)
> ic.lookup("java:comp/env/mail/MailSession");
> mailSession.setDebug(true);
> mailSession.setDebugOut(System.err);
> out.println("session = "+mailSession);
>
> MimeMessage msg = new MimeMessage(mailSession);
>
> msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
> InternetAddress("[EMAIL PROTECTED]")});
>
> msg.setSubject("Mail sent by MailerServlet");
>
> msg.setText("Hello");
>
> msg.setFrom(InternetAddress.getLocalAddress(mailSession));
>
> Transport.send(msg);
> } catch (Exception e) {
> e.printStackTrace(out);
> }
> }
> When I access the servlet, I am getting the following Exception.
> java.lang.IllegalStateException: Not connected
> at
> org.apache.geronimo.javamail.transport.smtp.SMTPTransport.sendMessage(SMTPTransport.java:356)
> at javax.mail.Transport.send(Transport.java:80)
> at javax.mail.Transport.send
> (Transport.java:46)
> at mailwebapp.MailerServlet.doGet(MailerServlet.java:64)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
> at
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(Geronim
RE: Recent OpenWire changes
Most informative, thanks Hiram. Is it correct that the C# client only supports tight marshalling at the moment? Regards, Mats -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: den 1 mars 2006 19:26 To: activemq-dev@geronimo.apache.org Subject: Recent OpenWire changes Hi Everybody, Just a quick heads up, openwire by default tries to encode commands as tight as possible on the wire to decrease bandwidth requirements. To do this, it currently uses a 2 pass algorithm where the first pass collects all boolean writes into a bit array and pre calculates the size of the command on the wire. The second pass writes the command to the stream. While this produces small on the wire size, it's a bit CPU intensive, so I made a change so that a loose encoding is also possible which marshals the messages in a single pass and avoids doing all the fancy things that the tight encoding was using. Using loose encoding should make sense if your broker is CPU bound and network bandwidth is not an issue. So if you look at the open wire classes you will now see a bunch of tightMarshal/Unmarshal and looseMarshal/Unmarshal methods. Another option that has been added is the ability to omit the command size prefix on the serialized commands. The command size prefix is actually only useful for non blocking implementations where we only want to unmarshal the command once it has been fully received. In normal blocking IO, knowing the size of the command in not necessary. By omitting the command size, we should be able to do more efficient marshaling of the command since we don't have to calculate the command size beforehand. These default options are still at what they were before (tight encoding and command size prefixing), but they can be negotiated between the client and server with the WireFormatInfo packet. Regards, Hiram
[jira] Commented: (GERONIMO-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
[
http://issues.apache.org/jira/browse/GERONIMO-1669?page=comments#action_12368485
]
Rick McGuire commented on GERONIMO-1669:
That's a different issue unrelated to the thing the Jira fixes. The use of
InternetAddress.getLocalAddress() checks a number of different system and
session properties to see if there is a local address defined, and returns null
if it is not. setFrom(), if it receiveds null, calls
InternetAddress.getLocalAddress() itself to resolve this (and it's gonna return
null again). To fix this, change the setFrom() line to use any dummy address
(setFrom(new InternetAddress("[EMAIL PROTECTED]")).
On checking this out, I discovered the G version doesn't do all the same checks
that the Sun impl documents, but that's another Jira issue to take care of.
> javamail Transport.send() is not issuing connect() on the transport before
> sending the message.
> ---
>
> Key: GERONIMO-1669
> URL: http://issues.apache.org/jira/browse/GERONIMO-1669
> Project: Geronimo
> Type: Bug
> Components: mail
> Versions: 1.x
> Reporter: Rick McGuire
> Attachments: GERONIMO-1669.patch
>
> This was reported on the geronimo user list (problem report attached below).
> The error is occuring because the Transport.send() code is failing to
> surround the sendMessage() call with connect() and close() calls on the
> transport, resulting in the connection failure. Additionally, this code is
> not properly merging send failures for multiple transports into a single
> SendFailedException with proper reporting of which addresses the message was
> not sent to.
> Hi Alex,
> I am trying to send mail from a servlet. Here is my geronimo-web.xml:
>
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
> xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> configId="MailWebApp/MailWebApp">
>
> geronimo/geronimo-mail/1.2-SNAPSHOT
>
>
> geronimo/geronimo-javamail-transport/1.2-SNAPSHOT
>
> /MailWebApp
> false
>
> mail/MailSession
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
>
>
>
>
> smtp
> 9.182.150.56
> false
>
> mail.debug=true
> [EMAIL PROTECTED]
> mail.smtp.port=25
>
>
> Here are the imports and the doGet() method in my servlet.
> import javax.mail.Session;
> import javax.mail.Transport;
> import javax.mail.Message.RecipientType;
> import javax.mail.internet.InternetAddress;
> import javax.mail.internet.MimeMessage;
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>
> response.setContentType("text/plain");
>
> PrintWriter out = response.getWriter();
>
> try {
> InitialContext ic = new InitialContext();
>
> Session mailSession = (Session)
> ic.lookup("java:comp/env/mail/MailSession");
> mailSession.setDebug(true);
> mailSession.setDebugOut(System.err);
> out.println("session = "+mailSession);
>
> MimeMessage msg = new MimeMessage(mailSession);
>
> msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
> InternetAddress("[EMAIL PROTECTED]")});
>
> msg.setSubject("Mail sent by MailerServlet");
>
> msg.setText("Hello");
>
> msg.setFrom(InternetAddress.getLocalAddress(mailSession));
>
> Transport.send(msg);
> } catch (Exception e) {
> e.printStackTrace(out);
> }
> }
> When I access the servlet, I am getting the following Exception.
> java.lang.IllegalStateException: Not connected
> at
> org.apache.geronimo.javamail.transport.smtp.SMTPTransport.sendMessage(SMTPTransport.java:356)
> at javax.mail.Transport.send(Transport.java:80)
> at javax.mail.Transport.send
> (Transport.java:46)
> at mailwebapp.MailerServlet.doGet(MailerServlet.java:64)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextV
Re: [jira] Created: (GERONIMO-1665) axis module migration to Maven2
2006/3/1, Henri Yandell (JIRA) : > axis module migration to Maven2 Hi Henri, Welcome on board, Henri! I'm more confident now the migration will really succeed. Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Migrating to maven 2
2006/3/1, Prasad Kashyap <[EMAIL PROTECTED]>: > Dain, your wish has been granted. Here is a humble beginning > > http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Migration+to+Maven2 Great work, Prasad! It's a pleasure to work with you and *try* to keep your pace ;) But...why do we get used to use Wiki? Wouldn't it be better off if we talked it over here, in the dev mailing list, and put it in the JIRA task, afterwards? I think it's much better from historical perspective when all changes are easily found in the archive(s). > Prasad. Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Migrating to maven 2
2006/3/1, Dain Sundstrom <[EMAIL PROTECTED]>: > What does "converted" mean? Does it mean that all unit tests pass? Yes. That's the absolute minimum to mark a module as converted. > How about conversion to the maven2 directory structure? That's interesting question. Shall we do that [|now|at all]? Do you see any benefits of having it done? I can't see any, but would be happy to hear I'm wrong ;) > -dain Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Migrating to maven 2
2006/3/2, anita kulshreshtha <[EMAIL PROTECTED]>: > Prasad, > Thanks! The version no. for > geronimo-javamail_1.3.1_spec jar is 1.1-SNAPSHOT in > maven1 build and 1.2-SNAPSHOT in maven2 build. There > is a working pom.xml for naming-builder but it is not > in the list in the parent pom.xml (rev > 382066). Thanks Anita! The solution's been checked in as revision 382362. I meant to do it yesterday, but had no much time. > Anita Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: ModuleBuilder - add initENC after addGBeans
Dain Sundstrom wrote: On Mar 1, 2006, at 10:06 AM, Dain Sundstrom wrote: On Mar 1, 2006, at 7:27 AM, David Jencks wrote: On Mar 1, 2006, at 3:56 AM, Gianny Damour wrote: Hi, I think that we need to split ModuleBuilder.addGBeans into two methods: addGBeans and initENC. addGBeans implementations perform GBean registrations as per the current approach. initENC is invoked after the addGBeans phase and implementations use this callback to build the ENC. The issue with the current implementation is that it is impossible to bind a GBean reference to the ENC if the referenced GBean is defined by a module which has not yet been processed by addGBeans. For instance, if a module A references a GBean added by a module B and if module A is processed before module B, then it is impossible to locate the referenced GBean as it has not yet been added to the registry. If there is no objection, I will start to work on it in the next couple of days. I would rather see us reduce the number of module builder phases than increase them :-) So far we have dealt with this problem by registering a gbean data for anything that could possibly be referenced in the ENC during the initContext phase. I'm also worried that changes of this nature could make merging the configid/1.1 changes into trunk almost impossible. Big +1 from me Should clarify... that was a big +1 to David Jencks. These changes will make configid/1.1 almost impossible to merge. Also, with the configid changes, we are simplifying (i.e., changing) the way references work, and my guess is you will no longer want to make the proposed change. Actually, I understood it this way :). If the simplified way of resolving references being implemented on the 1.1 branch defers the resolution of GBean references until after the registrations of all the GBeans added by the builders, then I assume that we no longer want this change. Anyway, after having thought about it a little bit more, I realized it was possible to defer the resolution of GBean references w/o having to add an extra method. ENCConfigBuilder.buildComponentContext adds to the EARContext a command to build the component context and returns an empty Map. In EARConfigBuilder.buildConfiguration, after the addGBeans phase, one retrieves and executes the command previously added to the EARContext. It is quite a pity that I did not think about it before my email :( Thanks, Gianny -dain
[jira] Commented: (GERONIMO-1667) Remove console-web module as it has now become obsolete
[ http://issues.apache.org/jira/browse/GERONIMO-1667?page=comments#action_12368481 ] Jacek Laskowski commented on GERONIMO-1667: --- I'll await some more responses by tomorrow before removing it. > Remove console-web module as it has now become obsolete > --- > > Key: GERONIMO-1667 > URL: http://issues.apache.org/jira/browse/GERONIMO-1667 > Project: Geronimo > Type: Bug > Components: console > Reporter: Prasad Kashyap > Assignee: Jacek Laskowski > Priority: Minor > > http://www.mail-archive.com/dev@geronimo.apache.org/msg18474.html -- 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-1667) Remove console-web module as it has now become obsolete
[ http://issues.apache.org/jira/browse/GERONIMO-1667?page=all ] Jacek Laskowski reassigned GERONIMO-1667: - Assign To: Jacek Laskowski > Remove console-web module as it has now become obsolete > --- > > Key: GERONIMO-1667 > URL: http://issues.apache.org/jira/browse/GERONIMO-1667 > Project: Geronimo > Type: Bug > Components: console > Reporter: Prasad Kashyap > Assignee: Jacek Laskowski > Priority: Minor > > http://www.mail-archive.com/dev@geronimo.apache.org/msg18474.html -- 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-1660) console application migration to Maven 2
[ http://issues.apache.org/jira/browse/GERONIMO-1660?page=comments#action_12368480 ] Jacek Laskowski commented on GERONIMO-1660: --- Sent a message to delete the console-web module to the dev mailing list. Will delete it unless there are objections. > console application migration to Maven 2 > > > Key: GERONIMO-1660 > URL: http://issues.apache.org/jira/browse/GERONIMO-1660 > Project: Geronimo > Type: Sub-task > Reporter: Prasad Kashyap > > The console-web module seems to be obsolete. It should be removed. The > console application is contained by the 3 components under the applications > dir. -- 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-1670) SMTPTransport not throwing correct exception for message send failures.
[ http://issues.apache.org/jira/browse/GERONIMO-1670?page=all ] Rick McGuire updated GERONIMO-1670: --- Attachment: GERONIMO-1670.patch Applied to the javamail-transport module in the main Geronimo tree. > SMTPTransport not throwing correct exception for message send failures. > --- > > Key: GERONIMO-1670 > URL: http://issues.apache.org/jira/browse/GERONIMO-1670 > Project: Geronimo > Type: Bug > Components: mail > Versions: 1.x > Reporter: Rick McGuire > Priority: Minor > Attachments: GERONIMO-1670.patch > > The SMTPTransport is throwing a simple MessagingException for failures due to > the SMTP DATA command. This sort of failure should be throwing a > SendFailedException with the address list information indicating that this > was a failure to all of the valid addresses (and also listing the invalid > addresses). > This was discovered while fixing 1669. -- 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-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
[
http://issues.apache.org/jira/browse/GERONIMO-1669?page=comments#action_12368479
]
Jacek Laskowski commented on GERONIMO-1669:
---
I was about to commit the patch, but was unable to pass the tests successfully
(mvn test). The exception was:
javax.mail.MessagingException: No local address defined
at javax.mail.internet.MimeMessage.setFrom(MimeMessage.java:298)
at
javax.mail.internet.MimeMessageTest.testFrom(MimeMessageTest.java:102)
Does the tests pass for you?
> javamail Transport.send() is not issuing connect() on the transport before
> sending the message.
> ---
>
> Key: GERONIMO-1669
> URL: http://issues.apache.org/jira/browse/GERONIMO-1669
> Project: Geronimo
> Type: Bug
> Components: mail
> Versions: 1.x
> Reporter: Rick McGuire
> Attachments: GERONIMO-1669.patch
>
> This was reported on the geronimo user list (problem report attached below).
> The error is occuring because the Transport.send() code is failing to
> surround the sendMessage() call with connect() and close() calls on the
> transport, resulting in the connection failure. Additionally, this code is
> not properly merging send failures for multiple transports into a single
> SendFailedException with proper reporting of which addresses the message was
> not sent to.
> Hi Alex,
> I am trying to send mail from a servlet. Here is my geronimo-web.xml:
>
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
> xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> configId="MailWebApp/MailWebApp">
>
> geronimo/geronimo-mail/1.2-SNAPSHOT
>
>
> geronimo/geronimo-javamail-transport/1.2-SNAPSHOT
>
> /MailWebApp
> false
>
> mail/MailSession
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
>
>
>
>
> smtp
> 9.182.150.56
> false
>
> mail.debug=true
> [EMAIL PROTECTED]
> mail.smtp.port=25
>
>
> Here are the imports and the doGet() method in my servlet.
> import javax.mail.Session;
> import javax.mail.Transport;
> import javax.mail.Message.RecipientType;
> import javax.mail.internet.InternetAddress;
> import javax.mail.internet.MimeMessage;
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>
> response.setContentType("text/plain");
>
> PrintWriter out = response.getWriter();
>
> try {
> InitialContext ic = new InitialContext();
>
> Session mailSession = (Session)
> ic.lookup("java:comp/env/mail/MailSession");
> mailSession.setDebug(true);
> mailSession.setDebugOut(System.err);
> out.println("session = "+mailSession);
>
> MimeMessage msg = new MimeMessage(mailSession);
>
> msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
> InternetAddress("[EMAIL PROTECTED]")});
>
> msg.setSubject("Mail sent by MailerServlet");
>
> msg.setText("Hello");
>
> msg.setFrom(InternetAddress.getLocalAddress(mailSession));
>
> Transport.send(msg);
> } catch (Exception e) {
> e.printStackTrace(out);
> }
> }
> When I access the servlet, I am getting the following Exception.
> java.lang.IllegalStateException: Not connected
> at
> org.apache.geronimo.javamail.transport.smtp.SMTPTransport.sendMessage(SMTPTransport.java:356)
> at javax.mail.Transport.send(Transport.java:80)
> at javax.mail.Transport.send
> (Transport.java:46)
> at mailwebapp.MailerServlet.doGet(MailerServlet.java:64)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
> at
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:273)
> at
> org.apache.geron
[jira] Created: (GERONIMO-1670) SMTPTransport not throwing correct exception for message send failures.
SMTPTransport not throwing correct exception for message send failures. Key: GERONIMO-1670 URL: http://issues.apache.org/jira/browse/GERONIMO-1670 Project: Geronimo Type: Bug Components: mail Versions: 1.x Reporter: Rick McGuire Priority: Minor The SMTPTransport is throwing a simple MessagingException for failures due to the SMTP DATA command. This sort of failure should be throwing a SendFailedException with the address list information indicating that this was a failure to all of the valid addresses (and also listing the invalid addresses). This was discovered while fixing 1669. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-1660) console application migration to Maven 2
2006/3/1, Prasad Kashyap (JIRA) : > [ http://issues.apache.org/jira/browse/GERONIMO-1660?page=all ] > > Prasad Kashyap updated GERONIMO-1660: > - > > Summary: console application migration to Maven 2 (was: console-web > module migration to Maven 2) > Description: The console-web module seems to be obsolete. It should be > removed. The console application is contained by the 3 components under the > applications dir. Hi, AFAIR, it was agreed that the module is no longer maintained and was replaced by the applications/console*. I haven't noticed that the module has already been deleted, so unless I hear objections I'll remove it tomorrow, say at 12 CET (GMT+1). Is 'svn rm console-web' enough to preserve the history and possibly bring it back to life in case of later need to do so? Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Updated: (GERONIMO-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
[ http://issues.apache.org/jira/browse/GERONIMO-1669?page=all ]
Rick McGuire updated GERONIMO-1669:
---
Attachment: GERONIMO-1669.patch
Applied to geronimo-spec-javamail module of the specs tree.
> javamail Transport.send() is not issuing connect() on the transport before
> sending the message.
> ---
>
> Key: GERONIMO-1669
> URL: http://issues.apache.org/jira/browse/GERONIMO-1669
> Project: Geronimo
> Type: Bug
> Components: mail
> Versions: 1.x
> Reporter: Rick McGuire
> Attachments: GERONIMO-1669.patch
>
> This was reported on the geronimo user list (problem report attached below).
> The error is occuring because the Transport.send() code is failing to
> surround the sendMessage() call with connect() and close() calls on the
> transport, resulting in the connection failure. Additionally, this code is
> not properly merging send failures for multiple transports into a single
> SendFailedException with proper reporting of which addresses the message was
> not sent to.
> Hi Alex,
> I am trying to send mail from a servlet. Here is my geronimo-web.xml:
>
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
> xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
> xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
> xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
> configId="MailWebApp/MailWebApp">
>
> geronimo/geronimo-mail/1.2-SNAPSHOT
>
>
> geronimo/geronimo-javamail-transport/1.2-SNAPSHOT
>
> /MailWebApp
> false
>
> mail/MailSession
>
>
> geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
>
>
>
>
> smtp
> 9.182.150.56
> false
>
> mail.debug=true
> [EMAIL PROTECTED]
> mail.smtp.port=25
>
>
> Here are the imports and the doGet() method in my servlet.
> import javax.mail.Session;
> import javax.mail.Transport;
> import javax.mail.Message.RecipientType;
> import javax.mail.internet.InternetAddress;
> import javax.mail.internet.MimeMessage;
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>
> response.setContentType("text/plain");
>
> PrintWriter out = response.getWriter();
>
> try {
> InitialContext ic = new InitialContext();
>
> Session mailSession = (Session)
> ic.lookup("java:comp/env/mail/MailSession");
> mailSession.setDebug(true);
> mailSession.setDebugOut(System.err);
> out.println("session = "+mailSession);
>
> MimeMessage msg = new MimeMessage(mailSession);
>
> msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
> InternetAddress("[EMAIL PROTECTED]")});
>
> msg.setSubject("Mail sent by MailerServlet");
>
> msg.setText("Hello");
>
> msg.setFrom(InternetAddress.getLocalAddress(mailSession));
>
> Transport.send(msg);
> } catch (Exception e) {
> e.printStackTrace(out);
> }
> }
> When I access the servlet, I am getting the following Exception.
> java.lang.IllegalStateException: Not connected
> at
> org.apache.geronimo.javamail.transport.smtp.SMTPTransport.sendMessage(SMTPTransport.java:356)
> at javax.mail.Transport.send(Transport.java:80)
> at javax.mail.Transport.send
> (Transport.java:46)
> at mailwebapp.MailerServlet.doGet(MailerServlet.java:64)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
> at
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:273)
> at
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at org.apache.catali
[jira] Created: (GERONIMO-1669) javamail Transport.send() is not issuing connect() on the transport before sending the message.
javamail Transport.send() is not issuing connect() on the transport before
sending the message.
Key: GERONIMO-1669
URL: http://issues.apache.org/jira/browse/GERONIMO-1669
Project: Geronimo
Type: Bug
Components: mail
Versions: 1.x
Reporter: Rick McGuire
This was reported on the geronimo user list (problem report attached below).
The error is occuring because the Transport.send() code is failing to surround
the sendMessage() call with connect() and close() calls on the transport,
resulting in the connection failure. Additionally, this code is not properly
merging send failures for multiple transports into a single SendFailedException
with proper reporting of which addresses the message was not sent to.
Hi Alex,
I am trying to send mail from a servlet. Here is my geronimo-web.xml:
http://geronimo.apache.org/xml/ns/j2ee/web-1.1";
xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1";
xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1";
xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1";
configId="MailWebApp/MailWebApp">
geronimo/geronimo-mail/1.2-SNAPSHOT
geronimo/geronimo-javamail-transport/1.2-SNAPSHOT
/MailWebApp
false
mail/MailSession
geronimo.server:J2EEApplication=null,J2EEModule=MailWebApp/MailWebApp,J2EEServer=geronimo,j2eeType=JavaMailResource,name=MailSession
smtp
9.182.150.56
false
mail.debug=true
[EMAIL PROTECTED]
mail.smtp.port=25
Here are the imports and the doGet() method in my servlet.
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.Message.RecipientType;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.setContentType("text/plain");
PrintWriter out = response.getWriter();
try {
InitialContext ic = new InitialContext();
Session mailSession = (Session)
ic.lookup("java:comp/env/mail/MailSession");
mailSession.setDebug(true);
mailSession.setDebugOut(System.err);
out.println("session = "+mailSession);
MimeMessage msg = new MimeMessage(mailSession);
msg.setRecipients(RecipientType.TO, new InternetAddress[] {new
InternetAddress("[EMAIL PROTECTED]")});
msg.setSubject("Mail sent by MailerServlet");
msg.setText("Hello");
msg.setFrom(InternetAddress.getLocalAddress(mailSession));
Transport.send(msg);
} catch (Exception e) {
e.printStackTrace(out);
}
}
When I access the servlet, I am getting the following Exception.
java.lang.IllegalStateException: Not connected
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.sendMessage(SMTPTransport.java:356)
at javax.mail.Transport.send(Transport.java:80)
at javax.mail.Transport.send
(Transport.java:46)
at mailwebapp.MailerServlet.doGet(MailerServlet.java:64)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:273)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:107)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
[jira] Created: (GERONIMO-1668) Support of dynamic EJBQL queries
Support of dynamic EJBQL queries Key: GERONIMO-1668 URL: http://issues.apache.org/jira/browse/GERONIMO-1668 Project: Geronimo Type: New Feature Components: OpenEJB Versions: 1.0 Reporter: Gianny Damour Assigned to: Gianny Damour Fix For: 1.1 This new feature covers the need to provide an API to compile and execute dynamic EJBQL queries. -- 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-1434) Allow GBeans to be bound into a component's java:comp/env namespace
[ http://issues.apache.org/jira/browse/GERONIMO-1434?page=all ] Gianny Damour reassigned GERONIMO-1434: --- Assign To: Gianny Damour > Allow GBeans to be bound into a component's java:comp/env namespace > --- > > Key: GERONIMO-1434 > URL: http://issues.apache.org/jira/browse/GERONIMO-1434 > Project: Geronimo > Type: Improvement > Components: kernel, naming > Versions: 1.0 > Reporter: Aaron Mulder > Assignee: Gianny Damour > Fix For: 1.1 > > Would be nice if proxies to GBeans could be placed in a component's private > JNDI space. > The 1.0 release includes a gbean-ref element in the jndiEnvironmentRefsGroup > that appears to hold the required settings. > David J notes that some code is present in the class is GBeanProxyReference > and there's some code that doesn't work in ComponentContextBuilder -- we just > need to add some stuff to ENCConfigBuilder for these and bind them directly. -- 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: heads-up: Servlet-2.5 & jetty 6 branch?
You might want to wait until the configId branch is finished and 1.1 is golden (about two weeks?). Other than that sounds good. Greg Wilkins wrote: All, I'm tuning back into G after zoning out for a while I'd like to started work on the jetty6 integration to provide servlet 2.5 The goals of the jetty 6 integration will be: + 2.5 servlet API. + annotation support + Simplify integration using Jetty 6 interceptor friendly architecture. + Use geronimo threadpool + Use Session API ( or iteration of that (see comments posted earlier)) as basis of session manager + Experiment with WADI and clustering integration + Better JACC specific security handler (perhaps to be back ported to Jetty) + Potentially use common server socket factories and eventually SSL Engine factories For this I'm going to created a branch geronimo/sandbox/servlet-2.5 and add geronimo-spec-servlet to geronimo/spec/branches/JEE5 I'm going for a full branch: + because I actually want to see how hard it will be to use svn to maintain a parallel dev branch. + I want some stability + I think there will be some moderately global changes that may affect multiple modules. + The branch will be a good place for a 2.5 tomcat module to be developed at the same time. everybody OK with this? I'd like to start this soonish, although I'm tempted to wait for maven2 to be working. cheers
Re: boot problem
In HEAD now and 1.1 when it comes out there will be a message indicating if the JDK level your using isn't supported so people will at least have a heads up. Given JDK 6 is on the horizon this sounds like an additional dependency. Dain, does XBean have this as one of the attributes so a check can be made? I'd hate to see multiple CARs (one for each JVM level). Paul McMahan wrote: Based on the number of problems people have encountered trying to use the 1.5 JRE I'd say this is a very prudent suggestion. I personally like the second approach best because IIUC it doesn't affect the schema. It might also be neat for Geronimo to have a stock GBean that compares the properties it gets passed against the runtime env and provides a clear error message and/or fails to start if they don't match. Applications/components with specific runtime reqs could optionally reference it in their plans. Just a thought... Best wishes, Paul On 3/1/06, John Sisson <[EMAIL PROTECTED]> wrote: It sounds like we could run into this issue in the future where a configuration (possibly provided by a third party) has a minimum JDK requirement. Would it make sense to have the minimum JDK requirements in the plan XML so we can gracefully skip loading configurations when the hosting VM does not meet the requirements? Another approach could be to specify configuration activation criteria (e.g. like Maven 2's activation element in the pom) so one could provide an assembly with some configurations for specific JDK levels or possibly for specific operating systems (e.g. if you have configurations that use JNI to provides access to particular O/S features) where the configurations only get started if they are running in the appropriate environment. Not high priority, but thought it might be worth discussing for the future.. John
