As a follow up to this - Stephen - has the SDS implemented "DELETE" and if so, what is the form of the commands. We could delete SDS objects that we are creating as part of our test protocol.
Laurel On May 3, 11:48 am, laurel <[EMAIL PROTECTED]> wrote: > Stephen, > > Actually you've put your finger right on the problem I was having. I > was accidentally putting a curnit.jar URL in when I had thought I was > putting a validJNLPURL in. Silliness in my code! Thanks for > providing your observations, which have helped me to find that bug. > > Sorry about all of the invalid data in portal 4. Each time the unit > tests are run on the portal code, we create actual curnits, offerings, > workgroups,jnlp'setc. The tests are automated and they are run ALOT > - many times daily when we are working on the code. Anything that > we've created which is invalid is because the SDS allowed invalid data > to go in there, and since we weren't retrieving and using the test > data generally, there wasn't any problem. But, as you have noted, you > are putting a lot more data checking (which is good!) - so we've > slowly been correcting our tests to use more valid data. > > If you clean out portal 4 now it is likely you will not get so much > invalid data in there in the future, as we have been correcting things > as you put more restrictions into place. Please feel free to wipe > portal 4 clean. > > Thanks again for leading me to my bug. > > Laurel > > On May 1, 10:37 am, Stephen Bannasch <[EMAIL PROTECTED]> wrote: > > > [fyi: Aaron should be on the sail-dev list -- right Aaron?] > > > Which SDS are you using? > > > I'm also curious which portal realm andjnlpyou are having problems with. > > > There are two portal realms setup for PRP: > > > 4: PAS Researcher Pack testing > > 6: Pas Researcher Pack > > > #4 looks to be full of malformed resources > > > Many of the 100 or sojnlpresources created point to google or point to a > > curnit jar. Seems like the SDS should prevent creation of invalid > > resources like this and return errors. > > > One of the reasons Aaron took the time to document how to create your own > > instatiation of an SDS is so that you cold easily do testing like this and > > just wipe out the data and start over. > > > For security reasons right now resources can't easily be deleted in the > > production database -- and at intervals we erase the dev database and > > modify and transfer all the data in the production database over to the dev > > database. > > > At 7:00 AM -0700 5/1/07, laurel wrote: > > > >Hi all, > > > >Hoping someone can help me with aJNLPissue which I am running into > > >via the portal. > > > >We are retrieving aJNLPfrom the SDS via HttpUnit calls and then > > >parsing the response using JDom (ie. > > >org.jdom.input.SAXBuilder.builder.build(responseStream)) > > > >The body of the response is as follows (but I've removed the text > > >within the <body> element because it is really long. > > > ><jnlp> > > > <name>d fault</name> > > > <last-modified>Fri Feb 23 10:40:02 -0500 2007</last-modified> > > > <body></body> > > > <portal-id>4</portal-id> > > ><url>http://www.encorewiki.org/download/attachments/2113/converted- > > >wise-dev.berkeley.edu-16704.jar</url> > > > <id>528</id> > > > <filename>converted-wise-dev.berkeley.edu-16704.jar</filename> > > > <always-update nil="true"></always-update> > > ></jnlp> > > > Take a closer look at the value of the url attribute: it's not a reference > > to ajnlp-- it's a reference to a jar! I can certainly imagine you won't be > > able to parse that. > > > Of course: > > > 1) the SDS shouldn't have allowed you to make this resource > > 2) if the sdsjnlpresource exists and it's url attribute doesn't point to a > > realjnlpthe SDS shouldn't process the resource the url points to any > > further and certainly not give it back to you! > > > In fact the sdsjnlp.body attribute should probably not be returned to you > > at all when you request a cml representation of thejnlp. The validity of > > the url you created could perhaps be reported back as an attribute of > > thejnlp.url element itself. > > -- > > - Stephen Bannasch > > Concord Consortium,http://www.concord.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
