Glad to hear that you have it sorted out. ERMailUtils.instantiatePage will create a session if you pass in the sessionDict parameter, but in that case session creation is likely not a surprise!
Chuck On 2015-04-27, 10:33 AM, "Timothy Worman" wrote: The component in question contained a repetition which was repeating over a “row” subcomponent. I decided to make a “light” version of the row component which relied only on WOString and WOHyperlink. I refactored the “heavier” row component to extend the new, lighter one - and which will only be used inside the app. Using ERMailUtils.instantiatePage does not create a session using the lighter version of the “row” component embedded. I think like Chuck said, something on the page was requiring a session. Tim Worman UCLA GSE&IS On Apr 25, 2015, at 3:28 PM, A.R.E Angela <[email protected]<mailto:[email protected]>> wrote: ERMailUtils.instantiatePage calls the component’s session() method which will create a Session. What I used to do in a distant past was to create a component with the normal constructor and pass to this constructor a dummy WOContext. I was using this technique to send batches of emails in the background, so not triggered by any UI action. Below you see how I used to create such a dummy WOContext. Hope this helps. Rudi Angela public WOContext dummyContext() { WOApplication app = Application.application(); String dummyUrl = app.cgiAdaptorURL() + "/" + app.name() + ".woa/wa/dummy"; WORequest request = app.createRequest("GET", dummyUrl, "HTTP/1.0", null, null, null); WOContext context = app.createContextForRequest(request); context._generateCompleteURLs (); return context; } On 24 apr. 2015, at 19:51, Chuck Hill <[email protected]<mailto:[email protected]>> wrote: I’d be surprised if you could NOT replace some bindings to avoid session creation. Chuck On 2015-04-24, 10:24 AM, "Timothy Worman" wrote: Yeah, I see what you’re saying. That’s why I mentioned in my first that the component contains things that I wouldn’t want to do by hand. I’ll have to examine the component and remind myself of which WOComponents require a session. I may be able to replace bits and pieces. Tim Worman UCLA GSE&IS On Apr 23, 2015, at 3:56 PM, Chuck Hill <[email protected]<mailto:[email protected]>> wrote: I think you are missing my point. It is not ERMailUtils.instantiatePage that is creating a session, it is the content of your component. The component you are e-mailing is using component actions, or referencing session.something, that is why it is creating a session (I think, this is what the cause usually is). You can log out a stack trace (new RuntimeException(“Session Created HERE”).printStackTrace() ) in the session constructor to see why and where they are being created. If you examine the component you should be able to see what needs to be changed. If you are mailing out component actions, the recipients are not going to be able to use them. Chuck On 2015-04-23, 3:47 PM, "Timothy Worman" wrote: Hi Chuck! The component that is being emailed isn’t being sent as the result of a user action. It is being sent as part of a quartz job. For a bunch of fetched EO’s, their global ID’s are passed to a method that uses ERMailUtils.instantiatePage to create an instance of the component for each EO. This all happens outside of userland. One thing I did was add Session.terminate in the finally block after try {_mailDelivery.sendEmail()} is called. Not sure if that is necessary. Tim Worman UCLA GSE&IS On Apr 23, 2015, at 3:07 PM, Chuck Hill <[email protected]<mailto:[email protected]>> wrote: Hi Tim, It is probably because your email is using component actions instead of direct actions. Component actions require a session and are definitely not what you want in an email. For WOHyperlink, as an example, you need to bind directActionName instead of action. Chuck On 2015-04-23, 12:25 PM, "Timothy Worman" wrote: In my app I am tracking session creation - as a way to sniff out some issues I’ve had with some going stray. Anyhow, I am sending NSArray<EOGlobalID> to a background task that sends emails using ERMailDeliveryHTML. These are component based emails. Low and behold, each and every one creates a new session. Certainly I understand why this could/would happen depending on the contents of the component/page. I am most curiouser about what approaches decent WO folk might use to avoid this. This is how I’m abusing things: for(Object aPersonGlobalIdObject : approverIds.toArray()) { EOGlobalID aGlobalID = (EOGlobalID)aPersonGlobalIdObject; MyComponent _component = (MyComponent) ERMailUtils.instantiatePage("MyComponent", null); _component.setGlobalId(aGlobalID); try { _component.sendThisComponentToPerson(); } other stuff…. } I had thought ERMailUtils.instantiatePage was made for doing this without creating a session? But I must have fooled myself. Tim Worman UCLA GSE&IS _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]<mailto:[email protected]>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/webobjects-dev%40olmeca.nl This email sent to [email protected]<mailto:[email protected]> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]<mailto:[email protected]>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com This email sent to [email protected]<mailto:[email protected]>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
