Re: AWS (CDN) GWT file deployment and 'Blocked a frame with origin' issue

[Joseph Lust]

Made progress, but the GWTP app is acting flaky after any 
deferredjs//.cache.js file is loaded. The error implied the 
functions being called are not in scope. The file is loaded and the request 
had the expected payload.

So, curious if anyone has run GWTP or similar split apps with the XS linker

*Steps taken to get things jiving*

1. I kicked on the XS linker in hopes code splitting would work with it. 
Needs more help, but this gets around frame security warnings.

2. RPC Asyncs kept pointing to the CDN, so I added the below to the RPC 
Asyncs

public static final PublicServiceAsync getInstance() {
if (instance == null) {
instance = (PublicServiceAsync) GWT.create(PublicServiceAsync.class);
ServiceDefTarget serviceDefTarget = ((ServiceDefTarget) instance);

String address = BrowserUtil.getHostpageUrl();
String oldUrl = serviceDefTarget.getServiceEntryPoint();

// if we're not local (dev) redirect to index.html URL
if (oldUrl.startsWith(GWT.getModuleBaseURL())) {
address = address + GWT.getModuleName() + "/" + 
oldUrl.substring(GWT.getModuleBaseURL().length());
serviceDefTarget.setServiceEntryPoint(address);
}
}
return instance;
}


3. The RPC Async interfaces kept throwing SOP issues, so I enabled CORS on 
the server side

4. Now RemoteServiceServlet is using the moduleName from the CDN url. 
However this does not match the server side layout, so it fails to fetch 
the *.gwt.rpc files. So I overrode RemoteServiceServlet with:

public class CustomRemoteServiceServlet extends RemoteServiceServlet {

public final static String MODULE_ALIAS = "app";

@Override
protected SerializationPolicy doGetSerializationPolicy(final 
HttpServletRequest request,
final String moduleBaseURL, final String strongName) {

// true client side relative location is the app name
String newModuleBaseURL = moduleBaseURL;
try {
URL url = new URL(moduleBaseURL);

StringBuilder builder = new StringBuilder();
builder.append(url.getProtocol());
builder.append("://");
builder.append(url.getHost());
builder.append("/");
builder.append(MODULE_ALIAS);
builder.append("/");
newModuleBaseURL = builder.toString();

} catch (MalformedURLException ex) {
// we have no affect
}

return super.doGetSerializationPolicy(request, newModuleBaseURL, 
strongName);
}
}


I hope that helps others attempting this, but I still need to solve that 
code splitting bit, so let me know if anyone's skinned that cat before. 
Thanks!



Sincerely,
Joseph



-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

AWS (CDN) GWT file deployment and 'Blocked a frame with origin' issue

[Joseph Lust]

Hey All, 

I know there have been 
many
 
CDN
 
relatedquestions
 here before, but I found no answers for this problem.

So here are the constraints:

   - Serve all RPC calls and index.html from EC2 site (i.e. www.site.com)
   - Serve everything else from CloudFront CDN (i.e. static.site.com)
   - Use GWTP with code splitting (so no XS Linker)
   - Use SSL for thinks like login

So, if you do this, you'll get the "Blocked a frame with origin "
http://static.site.com"; from accessing a frame with origin "
http://www.site.com ". Protocols, domains, and ports 
must match"

To my knowledge CORS does not help with this. CORS is for XHR requests, not 
frames.

Sadly I cannot just put index.html on the CDN and use passthrough for RPC's 
with CORS because CDN entries should be uniquely names, otherwise you must 
invalidate them and this will cause inconsistencies during deployment untli 
all 34 edge nodes eventually sync up (15min to 2 hours). Additionally, 
named SSL was just supported on 
Wednesday
 at 
a cost of $600/mo, otherwise the site can only be served from a very ugly 
CF URL. That's is too pricey for most anyone.

So, is there anyway to serve all the static files from a CDN with the 
index.html on another domain without using the XS linker (to retain code 
splitting)?

Thanks for your wisdom. I've been scraping scripts together to get this 
whole deployment automated and will put it all into a GWT on AWS post when 
we're finally deployed.

Sincerely,
Joseph

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.

[John V Denley]

Just had the same problem myself, and found that to fix it I had to do what 
you suggested, but I also had to manually create a "Prefs" key under 
JavaSoft too, as mentioned here:
http://www-01.ibm.com/support/docview.wss?uid=swg21496098

On Friday, 14 June 2013 02:02:26 UTC+1, QingFeng Du wrote:
>
> well well, 4 years later, I came across the same problem.
> here's my solution:
> open regedit.exe ( really hate Microsoft and their regedit.reg).
> change the permission of key: 
> HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft.Right click the icon, then change 
> the permission to full operation.
>
> On Saturday, June 27, 2009 3:03:20 PM UTC-4, Farinha wrote:
>>
>> The subject has it all. 
>>
>> Eclipse 3.4.2 
>> GWT Eclipse Plugin 
>> Windows 7 
>>
>> Thanks in advance for the help. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Uibinder inheriting and extending css classes (not just sharing them), best method?

[GWTter]

Hi Ryan,

I don't think you're way off, this is definitely a way to do it but there 
are a few caveats. 

You have to consider that in order to do it this way (assuming you're style 
is coming from another cssresource) you would have to:
- declare the cssresource that had the original style via ui:with and then 
make sure it is injected since uibinder only takes care of injecting the 
ui:style. 
- (maintainability): you would have to make sure to set all the styles that 
were set on the object originally (or any future ones if other classes are 
added) including your new extension since setStyleName would clear them all 
out (this would make your local style less maintainable and have to know 
more about the external one than just what it wanted to extend). With the 
extension approach even if the original style is deleted the local 
extension would still apply with no errors.

These were the things I was trying to avoid with this approach. Either way 
thanks for your reply, it should help clarify options.

-Seth

On Saturday, June 15, 2013 3:35:25 PM UTC+2, RyanZA wrote:
>
> I might be way off here, but is there any reason to extend myTestClass at 
> all? You can have multiple css classes per element, so simply doing:
>
> 
>   .myLOCALTestClass{ ...more properties specific for this binder...}
> 
>
> And then assigning both myTestClass and myLOCALTestClass to the element 
> should have the local specific changes overwriting the global ones.
>
> On Saturday, June 15, 2013 2:59:35 AM UTC+2, GWTter wrote:
>>
>> Hi Joseph,
>>
>> Thanks for the reply. You're right and I actually do this elsewhere 
>> extending cssresource interfaces and using the @shared which also works; 
>> it's definitely the way to go for larger extensions/additions that aren't 
>> as local.
>> However what I like about the ui:binder approach is you don't have to 
>> worry about ensuring the styles are injected and less boilerplate to 
>> utilize the cssresource (even though it's not THAT much of a hassle). The 
>> other really nice thing is you can override/extend styles more easily with 
>> the approach I described for local changes (at least in my opinion). That's 
>> why I just wanted to see if there was a way to extend it without having to 
>> specify the src like in the approach above, or if it's even recommended.
>>
>> Thanks again,
>>
>> -Seth
>>
>> On Friday, June 14, 2013 6:01:12 PM UTC+2, Joseph Lust wrote:
>>>
>>> Seth,
>>>
>>> Currently I can do this by setting >>> src='/MyCss.css"> in A and B and it works nicely, uibinder 
 takes care of injecting the styles and everything. However I'm not sure if 
 this is the best way. There's also the issue that if I move A and B then 
 the relative path breaks (since absolute paths still aren't 100% 
 functional 
 issue#7230).
  
 Does anyone have a clue or is this the preferred method?

>>>
>>> You might want to look at this previous 
>>> answer.
>>>  
>>> If you do the overriding in the Java class backing your UI binder, then the 
>>> refactoring worries won't be a problem. You can still handle the 
>>> refactoring in UiBinder, but you'll have to set Eclipse (or IDE of choice) 
>>> to do FQN replacements in all .xml files.
>>>
>>>
>>> Sincerely,
>>> Joseph
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Uibinder inheriting and extending css classes (not just sharing them), best method?

[RyanZA]

I might be way off here, but is there any reason to extend myTestClass at 
all? You can have multiple css classes per element, so simply doing:


  .myLOCALTestClass{ ...more properties specific for this binder...}


And then assigning both myTestClass and myLOCALTestClass to the element 
should have the local specific changes overwriting the global ones.

On Saturday, June 15, 2013 2:59:35 AM UTC+2, GWTter wrote:
>
> Hi Joseph,
>
> Thanks for the reply. You're right and I actually do this elsewhere 
> extending cssresource interfaces and using the @shared which also works; 
> it's definitely the way to go for larger extensions/additions that aren't 
> as local.
> However what I like about the ui:binder approach is you don't have to 
> worry about ensuring the styles are injected and less boilerplate to 
> utilize the cssresource (even though it's not THAT much of a hassle). The 
> other really nice thing is you can override/extend styles more easily with 
> the approach I described for local changes (at least in my opinion). That's 
> why I just wanted to see if there was a way to extend it without having to 
> specify the src like in the approach above, or if it's even recommended.
>
> Thanks again,
>
> -Seth
>
> On Friday, June 14, 2013 6:01:12 PM UTC+2, Joseph Lust wrote:
>>
>> Seth,
>>
>> Currently I can do this by setting >> src='/MyCss.css"> in A and B and it works nicely, uibinder 
>>> takes care of injecting the styles and everything. However I'm not sure if 
>>> this is the best way. There's also the issue that if I move A and B then 
>>> the relative path breaks (since absolute paths still aren't 100% functional 
>>> issue#7230).
>>>  
>>> Does anyone have a clue or is this the preferred method?
>>>
>>
>> You might want to look at this previous 
>> answer.
>>  
>> If you do the overriding in the Java class backing your UI binder, then the 
>> refactoring worries won't be a problem. You can still handle the 
>> refactoring in UiBinder, but you'll have to set Eclipse (or IDE of choice) 
>> to do FQN replacements in all .xml files.
>>
>>
>> Sincerely,
>> Joseph
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to play audio from the jar?

[Jens]

>
> And is mp3 a format that most browsers support?


To support all browsers that support HTML 5 audio you would need mp3 as 
well as ogg.

Browser support for HTML 5 audio: http://caniuse.com/#search=audio
Audio formats: http://www.w3schools.com/html/html5_audio.asp

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to play audio from the jar?

[Lothar Kimmeringer]

Hi Magnus,

Am 15.06.2013 03:58, schrieb Magnus:

> so the URL would be "/audio/file.mp3"? Where is the root?

http-root per Webapp is in the directory war of a GWT-project.
The URL Jens provided as example for a file residing in
war/audio/ missed the audio-directory, so the complete
URL would be http:audio/file.mp3.
The program base URL can be got by calling
GWT.getModuleBaseURL() so you can create the URL with
GWT.getModuleBaseURL() + "audio/file.mp3"
so you don't need to hardwire the names in your source.

> And is mp3 a format that most browsers support?

No, but what formats are supported wasn't your question so
Jens used a common format as example. I suppose you look
at the doumentation of the class you want to use, what formats
can be used.


Regards, Lothar

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.