Well firstly I believe I've located some relevant code. The page for the bug I'm working on shows that the component is wst.wsdl. Using this information I happened upon 2 packages: org.eclipse.wst.wsdl and org.eclipse.wst.wsdl.ui. I hoped that these packages would contain some code that could point me in the right direction, and fortunately I found one file that could prove interesting. Under the UI package I found another package called org.eclipse.wst.wsdl.ui.internal.properties.sections. Within this package I found a java file called W11ExtensionsSection. Success? I hope so. I feel like this could be a big break since within this file I found references to two buttons called addButton and removeButton. As my previous post explained, the section of the UI I'm focusing on has Add and Delete buttons, so these references could possibly have something to do with those 2 particular buttons.
I've been unable to check as to whether or not the code is relevant. In my previous post I showed a screenshot of the WSDL editor in my main Eclipse window. When I try to debug in a new Eclipse Application, for some reason the WSDL editor isn't there. I've decided to look to the Eclipse Webtools Newsgroup for help, so hopefully in time I'll have the answer to my problem.
I've thought about what I can submit for a 0.4 Release. I definitely won't be able to make a patch for this fix until a later release, so I'm not sure what I can create in-between. Perhaps a simple patch making a slight change to the UI? I'll have to discuss this with Dave.
Thursday, January 29, 2009
Tuesday, January 27, 2009
Switching Bugs
Well, after some difficulty (mostly due to the slightly vague instructions) trying to re-create Bug 142301, I managed to get it done. However, it seems like the bug has already been fixed.
It's hard to tell since the bug is from 2006 and I imagine the UI has changed since then, so some of the page names in the wizard (ie. "Web Service Java Bean Identity Page") seem out of date. I originally stumbled on this page which is a guide on how to use the Web Service wizard, from the screenshots it didn't seem like there was a "Web Service Java Bean Identity" page, thus I figured I wasn't in the right wizard.
I tried the WSDL wizard since the bug page mentions attempting to improperly name a .WSDL file. In this wizard I found what I was looking for: a text box for naming the WSDL file. However, I found that my bug had already been addressed. As the top of the image shows, the necessary error message and disabled buttons appear when I try to add an * to the filename.
It's frustrating that I wasted my time on this bug, but I decided to trek on and luckily I stumbled upon another bug that caught my fancy. This description was even less informative then the last one, but looking at the Component and noticing that it was in wst.wsdl meant that it had something to do with a WSDL file.
I had already created an EJB Session bean when trying to re-create the first bug with this tutorial, and using that I created a Web Service with a WSDL file. I opened this file, checked the extensions tab in the properties window and was distraught to find that this bug also seemed to be addressed as the Delete button was disabled when according to the bug it shouldn't have been. However, when I switched to another tab and then back to the extensions tab I found that the button was in fact enabled when no extensions were present. Somehow changing focus between tabs re-enabled the button.
Well, I'm glad I at least got the re-creation of the bug out of the way. Now, my next problem is to find out where in the code this is occurring. I feel like if I can do that the actual change in code wouldn't be anything crazy, but then again with a big, unknown system like Eclipse you never know.
It's hard to tell since the bug is from 2006 and I imagine the UI has changed since then, so some of the page names in the wizard (ie. "Web Service Java Bean Identity Page") seem out of date. I originally stumbled on this page which is a guide on how to use the Web Service wizard, from the screenshots it didn't seem like there was a "Web Service Java Bean Identity" page, thus I figured I wasn't in the right wizard.
I tried the WSDL wizard since the bug page mentions attempting to improperly name a .WSDL file. In this wizard I found what I was looking for: a text box for naming the WSDL file. However, I found that my bug had already been addressed. As the top of the image shows, the necessary error message and disabled buttons appear when I try to add an * to the filename.
It's frustrating that I wasted my time on this bug, but I decided to trek on and luckily I stumbled upon another bug that caught my fancy. This description was even less informative then the last one, but looking at the Component and noticing that it was in wst.wsdl meant that it had something to do with a WSDL file.
I had already created an EJB Session bean when trying to re-create the first bug with this tutorial, and using that I created a Web Service with a WSDL file. I opened this file, checked the extensions tab in the properties window and was distraught to find that this bug also seemed to be addressed as the Delete button was disabled when according to the bug it shouldn't have been. However, when I switched to another tab and then back to the extensions tab I found that the button was in fact enabled when no extensions were present. Somehow changing focus between tabs re-enabled the button.
Well, I'm glad I at least got the re-creation of the bug out of the way. Now, my next problem is to find out where in the code this is occurring. I feel like if I can do that the actual change in code wouldn't be anything crazy, but then again with a big, unknown system like Eclipse you never know.
Saturday, January 24, 2009
0.4 Goals
For my 0.4 Release, I've been trying to find a bug to work on that could provide me with a good introduction to the Eclipse system. I came across Bug 142301, which states that there is a fix required for one of the wizards. The fix must not allow the user to enter an invalid filename (ie. something with *&^%$ characters). If the user attempts to enter an invalid filename, the Next and Finish buttons are to be disabled and a message needs to appear to notify the user.
I feel like this is a good bug to start off with, and thus I will be working on it for my 0.4 (and perhaps in future releases as well depending on how successful I am).
One thing I find disheartening is that there seems to be no IRC channel for Eclipse developers. I'm worried that I won't be able to receive the same kind of support from experienced developers that I enjoyed with Mozilla. However, Jordan has pointed me towards the Eclipse newsgroups, which apparently have plenty information. I hope so because I have no clue how to re-create this bug or where I can find the relevant code.
I feel like this is a good bug to start off with, and thus I will be working on it for my 0.4 (and perhaps in future releases as well depending on how successful I am).
One thing I find disheartening is that there seems to be no IRC channel for Eclipse developers. I'm worried that I won't be able to receive the same kind of support from experienced developers that I enjoyed with Mozilla. However, Jordan has pointed me towards the Eclipse newsgroups, which apparently have plenty information. I hope so because I have no clue how to re-create this bug or where I can find the relevant code.
Where do I Begin?
I don't know where. I guess I'll start with my last semester results. My patch for the source server project was accepted into Mozilla's tree, which I'm very proud of.
My results with the source server project make it all the more confusing as to why I'd be so hesistant to work on my new project. I won't spend this entire post psychoanalyzing myself, but sometimes I think it goes beyond simply being lazy. I wonder if it has something to do with my self-confidence. This was a problem last semester with the source server project. It took me so long to finally take a look at the system and get started, and this semester with my new project it's the same.
Oh yes, my new project. I will be working with Eclipse WTP this semester. Dave recommended it since I was looking to try something a little different, and Eclipse is all Java.
Like I said, this happened last semester. At the time I believed it was just me being lazy, but now that it's happening again I'm starting to wonder if it has something to do with my confidence as a programmer. It's wierd that I would feel that way still, I mean I felt the exact same way last semester but I overcame it and once I got into the project it was easy for me to keep going. But now here I am and the cycle continues. Like I said I attributed it to laziness originally, but now I believe that perhaps by understanding why I do it a little more, I can overcome it.
I don't want to make baseless excuses for myself but I seriously believe that in this case it might be true. I've never really thought of that before but now that I'm aware, I hope that I can fix it starting with this project, because I know I'm a capable programmer and I know that I have the ability to learn a new system and contribute to it.
I will be updating my blog with my 0.4 release info shortly, I figure it's a better idea to keep this stuff a seperate post.
I'm still not too warm to this whole blogging thing, however it's actually felt nice to get that off my chest.
My results with the source server project make it all the more confusing as to why I'd be so hesistant to work on my new project. I won't spend this entire post psychoanalyzing myself, but sometimes I think it goes beyond simply being lazy. I wonder if it has something to do with my self-confidence. This was a problem last semester with the source server project. It took me so long to finally take a look at the system and get started, and this semester with my new project it's the same.
Oh yes, my new project. I will be working with Eclipse WTP this semester. Dave recommended it since I was looking to try something a little different, and Eclipse is all Java.
Like I said, this happened last semester. At the time I believed it was just me being lazy, but now that it's happening again I'm starting to wonder if it has something to do with my confidence as a programmer. It's wierd that I would feel that way still, I mean I felt the exact same way last semester but I overcame it and once I got into the project it was easy for me to keep going. But now here I am and the cycle continues. Like I said I attributed it to laziness originally, but now I believe that perhaps by understanding why I do it a little more, I can overcome it.
I don't want to make baseless excuses for myself but I seriously believe that in this case it might be true. I've never really thought of that before but now that I'm aware, I hope that I can fix it starting with this project, because I know I'm a capable programmer and I know that I have the ability to learn a new system and contribute to it.
I will be updating my blog with my 0.4 release info shortly, I figure it's a better idea to keep this stuff a seperate post.
I'm still not too warm to this whole blogging thing, however it's actually felt nice to get that off my chest.
Wednesday, December 17, 2008
0.3 Release Submitted
Well, I've submitted my third patch, which I will be considering as my 0.3 release. Whether or not it gets accepted remains to be seen but I feel like I've done enough to submit a good 0.3.
Most of the issues I needed to correct were minor things such as naming conventions, however there were also some other issues that ted pointed out that I needed to fix.
The first was a change to the data block. Ted didn't like the fact that the SRCSRVTRG variable was set to HTTP_EXTRACT_TARGET. Instead he wanted this variable to point to a local target because SRCSRVTRG was supposed to resolve to the path that the file is extracted to. What I found is that while this is true for a CVS extraction, I believe it serves a different purpose when used for HTTP extraction.
When I run srctool on a pdb using the old CVS implementation, I see entries like this:
As you can see, the header file has a "cmd" which is run to retrieve the source file. The SRCSRVTRG is then set as a local path to tell srcsrv where to dump the file. However, in my HTTP implementation srctool showed this:
As you can see, the files no longer use a "cmd" but a "trg". I wasn't sure if this was related to HTTP_EXTRACT_TARGET or SRCSRVTRG so I experimented by changing SRCSRVTRG to ted's recommendation, and srctool showed this:
The trg was now the location of the xul.pdb file. This showed me that SRCSRVTRG was being used to determine where the file was located, and thus was being used differently than if the source server was using CVS. Testing in Visual Studio proved this, as the source server didn't know where to find the file. So, to sum things up, SRCSRVTRG had to remain the way it was.
I was also asked to remove the SRCSRVCMD command from the data block, as it wasn't being set to anything. I assumed I needed it as the srcsrv documentation said it was a required variable, but it turns out that I didn't need it so I was happy to remove it.
So, I was ready to submit a new patch when I found out that my entire solution didn't work in Visual Studio 2005! I had been testing on 2008 the entire time and it worked like a dream, however 2005 didn't seem to know how to do HTTP retrieval. After discussing this with ted and sending him my stuff, he got it working fine in WinDBG (I had tried WinDBG myself without any success but I must have done something wrong in the setup) so in the end not working in 2005 was ok with ted, he speculated that perhaps srcsrv wasn't properly implemented in 2005 and I'm inclined to agree based on what I've seen in my testing.
So, now that I've resolved these issues I feel confident about getting my project implemented in the tree. Maybe not with this patch, but eventually.
Most of the issues I needed to correct were minor things such as naming conventions, however there were also some other issues that ted pointed out that I needed to fix.
The first was a change to the data block. Ted didn't like the fact that the SRCSRVTRG variable was set to HTTP_EXTRACT_TARGET. Instead he wanted this variable to point to a local target because SRCSRVTRG was supposed to resolve to the path that the file is extracted to. What I found is that while this is true for a CVS extraction, I believe it serves a different purpose when used for HTTP extraction.
When I run srctool on a pdb using the old CVS implementation, I see entries like this:
[e:\fx19rel\winnt_5.2_depend\mozilla\layout\style\nsrulenode.h] cmd: cvs.exe -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot checkout -r 1.64 -d 1.64 -N mozilla/layout/style/nsRuleNode.h
As you can see, the header file has a "cmd" which is run to retrieve the source file. The SRCSRVTRG is then set as a local path to tell srcsrv where to dump the file. However, in my HTTP implementation srctool showed this:
[c:\mozilla\src\toolkit\xre\nsupdatedriver.h] trg: http://hg.mozilla.org/mozilla-central/raw-file/3611062ed098/toolkit/xre/nsUpateDriver.h
As you can see, the files no longer use a "cmd" but a "trg". I wasn't sure if this was related to HTTP_EXTRACT_TARGET or SRCSRVTRG so I experimented by changing SRCSRVTRG to ted's recommendation, and srctool showed this:
[c:\mozilla\src\toolkit\xre\nsupdatedriver.h] trg: C:\mozilla\symbols\xul.pdb\....
The trg was now the location of the xul.pdb file. This showed me that SRCSRVTRG was being used to determine where the file was located, and thus was being used differently than if the source server was using CVS. Testing in Visual Studio proved this, as the source server didn't know where to find the file. So, to sum things up, SRCSRVTRG had to remain the way it was.
I was also asked to remove the SRCSRVCMD command from the data block, as it wasn't being set to anything. I assumed I needed it as the srcsrv documentation said it was a required variable, but it turns out that I didn't need it so I was happy to remove it.
So, I was ready to submit a new patch when I found out that my entire solution didn't work in Visual Studio 2005! I had been testing on 2008 the entire time and it worked like a dream, however 2005 didn't seem to know how to do HTTP retrieval. After discussing this with ted and sending him my stuff, he got it working fine in WinDBG (I had tried WinDBG myself without any success but I must have done something wrong in the setup) so in the end not working in 2005 was ok with ted, he speculated that perhaps srcsrv wasn't properly implemented in 2005 and I'm inclined to agree based on what I've seen in my testing.
So, now that I've resolved these issues I feel confident about getting my project implemented in the tree. Maybe not with this patch, but eventually.
Tuesday, December 9, 2008
0.3 Update #2, failed review again :(
Well, it seems ted has found some more problems with my patch so I'll have to try again. I'm still very optimistic that I can get this done on time however I'm in the middle of exam week so it will take some time before my next patch is created. Stay tuned.
Monday, December 1, 2008
0.3 Update
Well, it's been awhile since my last post but I'm in overdrive mode for some of my other classes so unfortunately I've gotten a little behind on my 0.3. Luckily, I believe I'm close to having my patch accepted.
I guess I should explain that my first review didn't go so well. Ted pointed out a few things that he didn't like about my patch (one of which was a dumb mistake on my part) but fortunately none of the required changes was difficult (mostly naming conventions and a syntax error inside of the data block) and Ted even mentioned that my patch was close. So, I've uploaded my next patch and I'm hoping for the best.
I guess I should explain that my first review didn't go so well. Ted pointed out a few things that he didn't like about my patch (one of which was a dumb mistake on my part) but fortunately none of the required changes was difficult (mostly naming conventions and a syntax error inside of the data block) and Ted even mentioned that my patch was close. So, I've uploaded my next patch and I'm hoping for the best.
Subscribe to:
Posts (Atom)