Dev Team:

I am following in Robson's footsteps a few day later and have this regression to report:

java/server/src/main/webapp/WEB-INF/web.xml

This commit: r957079 | johnh | 2010-06-22 17:23:06 -0600 (Tue, 22 Jun 2010) | 5 lines

added these lines:

 <servlet-mapping>
   <servlet-name>accel</servlet-name>
   <url-pattern>/*</url-pattern>
 </servlet-mapping>

Unfortunately, this hides the /samplecontainer/* paths used to get the sample container and test gadgets running using "mvn -Prun".

Workaround is to comment out the mapping, but of course that might be breaking something else!

Thanks,

Randy Watler

John Hjelmstad wrote:
@Paul, I'm inclined to add support for ContainerConfig expansions of
${props.KEY}, though I admit I've lost track of all the little particulars
in this issue that make for a clean fix. Thoughts?

--j

On Mon, Jun 21, 2010 at 8:42 PM, Robson Dantas <[email protected]> wrote:

Paul, thanks, worked.

But as you mentioned before, the hardcoded things are just making the jetty
launch a bit harder :-)

1- If I change defaultShindigTestHost to port 8080 and run mvn, tests fail;
2- If I let it to 9003, dont run.

Make it work using two ways:

1- run jetty (mvn -Prun), and change container.js inside
work/webapp/WEB-INF/classes/containers/default and restart jetty again.
2- modifying all test files to use another port.

Regards,

Robson Dantas

2010/6/21 Paul Lindner <[email protected]>

I just committed a fix for this.

On Mon, Jun 21, 2010 at 6:45 PM, Robson Dantas <[email protected]>
wrote:

Hi Paul!

Yes, it worked. But updated the code right now and build is broken.

-Robson Dantas

2010/6/21 Paul Lindner <[email protected]>

Change references to 9003 in config/container.js to 8080 and things
should
start working.

Some of the new UriManagers are hard coded to port 9003 which is used
for
tests.  We really ought to fix this.

The tests should use a dynamic port based on an environment variable.
 (generated from Maven Build Helper --
http://mojo.codehaus.org/build-helper-maven-plugin/)

In the absence of this the value of jetty.port or 8080 should be
used.
On Mon, Jun 21, 2010 at 2:49 PM, John Hjelmstad <[email protected]>
wrote:
OK, so it sounds like 'gadgets undefined' as well as gadgets not
rendering
are both to do with whatever the underlying cause is of the 404,
since
the
gadgets symbol is defined in that call.

You should be able to hit that JS endpoint directly in your browser
and
get
results. Your console should tell you why the connection was
aborted,
if
it's a Shindig-related issue. Otherwise it could be parallel.

It's a little curious to me that the gadget is including this
aggregated
extern JS in the first place btw... that behavior is supposed to be
turned
off by default..

--j

On Mon, Jun 21, 2010 at 1:10 PM, Robson Dantas <
[email protected]
wrote:

2010/6/21 John Hjelmstad <[email protected]>

On Sun, Jun 20, 2010 at 4:58 PM, Robson Dantas <
[email protected]
wrote:

Hi guys,

I'm making some experiments using shindig, and I'm quite
familiar
with
PHP
version. Yesterday, tried to setup Java Shindig, but it was
broken.
Today
saw an update on svn which allowed me to compile and run.
(mvn
and
then
mvn
-Prun)

The documentation is a bit outdated and would be great if
you
provide
some
help:

1- WARNING: Couldn't load OAuth signing key.  To create a
key,
run:
 openssl req -newkey rsa:1024 -days 365 -nodes -x509 -keyout
testkey.pem
\
    -out testkey.pem -subj '/CN=mytestkey'
 openssl pkcs8 -in testkey.pem -out oauthkey.pem -topk8
-nocrypt
-outform
PEM

Then edit gadgets.properties and add these lines:
shindig.signing.key-file=<path-to-oauthkey.pem>
shindig.signing.key-name=mykey

gadgets.properties doesn't exist. A similar file which i
found
is
shindig.properties, but modifying over there, the message
continues
to
appear when starting.

config/shindig.properties
Ok . Modified and ran mvn again, worked.



2- I'm getting a 404 message on firebug, with a call to this
url:

http://localhost:9003/gadgets/js/auth-refresh:core:core.config:core.io:core.json:core.legacy:core.log:core.prefs:core.util:dynamic-height:dynamic-height.util:flash:globals:locked-domain:opensocial:opensocial-0.8:opensocial-0.9:opensocial-base:opensocial-data:opensocial-data-context:opensocial-jsonrpc:opensocial-reference:rpc:security-token:shindig.auth:views:xmlutil.js?container=default
Unclear, any more context?
Steps: downloaded latest code from SVN, ran a sample which is
inside
readme:


http://localhost:8080/gadgets/ifr?url=http://www.labpixies.com/campaigns/todo/todo.xml
Loading firebug, network tab, there's a request with status
"aborted"
to:
http://localhost:9003/gadgets/js/auth-refresh:core:core.config:core.io:core.json:core.legacy:core.log:core.prefs:core.util:dynamic-height:dynamic-height.util:globals:locked-domain:opensocial:opensocial-0.8:opensocial-0.9:opensocial-base:opensocial-jsonrpc:opensocial-reference:rpc:security-token:setprefs:shindig.auth:views.js?container=default&nocache=0&debug=0&v=24ba52827d6f6b85291080cbeed88035
Switching to console tab:

Errors printed on firebug:
gadgets is not defined
[Break on this error] gadgets.util.registerOnLoadHandler(load);
ifr?ur...odo.xml (linha 529)

gadgets is not defined
[Break on this error] var mMENU =
gadgets.io.getProxyU..._footer.js",{refreshInterval:21600});
ifr?ur...odo.xml (linha 534)

gadgets is not defined
[Break on this error]
<script>gadgets.util.runOnLoadHandlers();</script></body></html>
ifr?ur...odo.xml (linha 541)

Uploaded a printscreen to my picasa account. See:


http://picasaweb.google.com.br/gdguiadogps/Personalstuff?authkey=Gv1sRgCLro3Ojs0u-ncA#


3- In README file, there's a paragraph:
Read javascript/README for instructions for using the
Shindig
Gadget
Container JavaScript to enable your page to render Gadgets.

But this file doesn't exist, either.

Moved to content/README
Ok.



4 - To finish it up, gadgets are not being rendered. All
app's
are
showing
a
gadgets is not defined message in firebug;

Depends on how you're starting things up. Need more context on
what's
actually in the gadget render.
Details above (item 2). Btw, my environment:

Ubuntu 10.04 running kernel 2.6.32-22 64 bit
Java version 1.6.0_18
MVN:
Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_20
Java home: /opt/jdk1.6.0_20/jre
Default locale: pt_BR, platform encoding: UTF-8
OS name: "linux" version: "2.6.32-22-generic" arch: "amd64"
Family:
"unix"
Let me know if it's enough.

Thanks

Robson Dantas



Reply via email to