Mark E Hansen

Sure: http://www.lmgtfy.com/?q=servlet+jsp+tutorial

When the user changes the value, you're going to want to go back to the Servlet and let it handle the update of the data. It should then respond with a new page which will show the user the result of the update (perhaps it will be the same page, showing the same data with just the addition of a message at the top which says that the update was successful).

Again, have a look at the Servlet/JSP tutorials - they will help you get the hang of this Model/View/Controller design pattern and it will me much easier to then understand where you need to do which parts.

Good luck.

You're on the right track, except that you're not using a JSP page - instead you're having the Servlet emit the HTML directly. You might find it easier to use a JSP page. There are lots of easy-to-follow Servlet/JSP tutorials available so just Google that and follow one or two. You'll quickly get the idea. As far as generating the page the way you are, just mock up an HTML page and make it work the way you want, then adjust your Servlet to generate that.

The tutorials will really help because they will show you how to wire the Servlet to the JSP (or the JSP to the Servlet - depending on how you look at it).

Alice: If your end DefEnv tag correct? What about the <Property> element inside the <DriverProperties> element?
Each element is made up of a start tag and and end tag, as in <mytag> </mytag>. If an element has no content, it can be abbreviated as <mytag/>

You said that you wanted to only remove those environment elements which have a particular value, but your sample code doesn't even refer to a value element?

The environment element is the element which starts with <Environment id="Test"> and ends with </Environment>. Is that what you're wanting to remove? Those two tags and all the content contained within them?

The Value element is actually quite deep within your sample XML: DefEnv/Environment/DB/DriverProperties/Value.

What exactly are you trying to remove and what basis do you want to use to locate the element to be removed?

It's hard sometimes to see the relationship between the JSP page and the Servlet. Think of it this way - the Servlet is the place where the application logic happens. The JSP page is just the View where the user is shown the result of the Servlet doing its action(s) and can provide input/actions.

Think about the servlet as the initial point - where your web application user goes first. Your servlet can detect that the user hasn't seen the JSP page yet, so it does a forward (or whatever you want) to the JSP page - providing any data the JSP page will need (like, for example, the values that should appear in the drop down control).

You can include an Edit button on the JSP page so the user can select an entry in the drop down control and then click on Edit. What happens then? What if the Edit button actually went back to the servlet?. The servlet knows where the application is based on the parameters passed when the edit button was clicked, so it can do a forward to the "edit" JSP page with whatever information that page needs to allow the user to edit the value. When the user clicks on the Submit button on the edit page, it goes back to the servlet ...

I hope you can see where I'm going

Sounds like a fun challenge. Good luck!

I just wanted to pass along what I ended up doing. I read both files using XML readers, creating instances of Document objects. I then went through the elements in the "override" document and used XPaths to find the associated elements in the "base" document. I then replaced the element in the base document with the one from the override document.

Once this process is done, I then used JAXB to unmarshal the resulting XML into the generated classes (the classes generated by JAXB based on the schema for the XML).

This gives me exactly what I was looking for. Thanks to anyone who looked at my question.

We have a process which needs to read a rather complicated XML file and then apply a set of "override" values to the result. Using JAXB and the XML schema, we've generated Java classes to represent the data and when I use JAXB to unmarshal the main XML file, it works fine. The Override XML file, however, just contains a small number of elements which are meant to override the corresponding elements in the main XML file.

The intent is that we'll read in the main XML file which will initialize the data instance, then read in the override XML file, go through the elements contained within and update the data instance.

The problem is that the override XML file contains elements which refer to other common elements using IDREFs and these common elements are not in the override file. When we use JAXB to read in the override XML file, it replaces the reference with "null". Is there any way I can get the parser to ignore the fact that the element wants to refer to another element and just let me see what the reference id value is?

One option I can think of is to create (by hand, I guess) a set of data classes specifically for the elements used in the override files such that they don't employ the IDREFs. Then I would be able to read the raw data - but this would be a lot of work and introduce a dependency on these classes and any changes which may be made to the structure of the override XML files in the future.

Thanks for any pointers.

It's just a guess, but it looks like there is strange data in the <samplerData> element

Yes, it's been so long I don't remember for sure. I do know that we had problems with Swing application running on a Linux host
and displaying to a Windows X Server that were resolved by forcing the Motif look and feel. Good luck.

Rob Spoor wrote:Odd, I've worked with PicketLink and it works just fine like that. Of course it should also be possible to sign other parts like you do.

To be honest, I'm not sure if the fact that the Assertion needs to be signed and not the entire response is a SAML 2.0 thing or a limitation of our implementation. I inherited the code and was told (by the original author) that it had to be that way.

Rob Spoor wrote:As I said before, without that namespace declaration the document is not valid XML. That could well be the root of your problems. Make them include it.

Thanks Rob!

Rob Spoor wrote:I take it there is a reference to the saml namespace (xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion")?

I see no mention of "xmlns:saml" in the customers XML document at all.

Rob Spoor wrote:What happens if you try to validate the response instead of only the assertion? I've so far only seen signatures that refer to the entire response. Of course this would mean that the other side would be incorrectly signing their documents.

This is for a SAML 2.0 Response, which is build a very specific way. The customer must digitally sign the SAML Assertion, then embed the (now signed) assertion in the SAML Response.
If they sign the whole response, it will no longer work. I can look at the SAML Response they are sending and see that it appears to be constructed properly (as far as what is signed goes).
In other words, the Signature element is inside the Assertion element, which is what they do when signing the Assertion. When the Response is signed, the Signature element would be inside the Response element (a sibling of the Assertion element).

Also, the validation call shows that the signature validates okay - it's just the reference that does not. Also, the Reference element includes a URI attribute which identifies the "thing" the signature is signing, and this correctly references the ID attribute value of the Assertion element.

It sure seems like they've signed it correctly. I keep coming back to the namespace used by the Assertion element. They way this customer has done it is certainly different than any of our other customers, and contrary to how I thought it had to be done.

Thanks,

We have a web application which allows SSO authentication using SAML 2.0

The customer will use their federated server (various flavors) to generate an HTTP Post request with a SAML Response which contains a digitally-signed SAML Assertion.

Our code will take the SAML Assertion and validate the digital signature.

We basically follow the code examples from the following page: http://docs.oracle.com/javase/7/docs/technotes/guides/security/xmldsig/XMLDigitalSignature.html

Under the section titled "What if the XML Signature Fails to Validate, it states that we can do a couple things to see what actually failed: The signature, or one (or more) of the reference elements.

In our customer's case, the Signature element has just one Reference element and it is referencing the SAML Assertion element.

The verification check is failing. It states that the signature validates okay, but the reference does not.

Note that the customer and I have double-checked that we have the correct public key certificate associated with the private key certificate they are using to sign the assertion.

I'm not sure what to check at this point. The customer claims that they use their software to connect to dozens of other vendors without any problems and so they feel the problem is on our side.

What can I do to determine why the reference element is not validating?

I did notice one interesting thing when looking at their SAML Assertion: The xmlns attributes are not what we normally get from our other customers. Here is what theirs looks like:
<saml:Assertion xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="2.0" ID="pfx4d77d707-998e-4a8b-e2d7-1cd836e35de0" IssueInstant="2013-07-18T19:20:34Z"> Notice that the Assertion element uses the "saml" namespace, but the xmlns attribute shows "xmlns:xs" instead of "xmlns:saml". Could this be the problem?

If so, is there something that needs to be done to our code (again, we're just using the code as shown by the above referenced Oracle page) to allow us to accept an assertion built this way?

Thanks,

Thanks. I tried that (and all the flags documented on that page) and nothing helped.
I tried turning on the logging, but it just says things like drawing lines, filling polygons, etc. Nothing to indicate why the drop down control won't work (or the other problems).

Any other ideas?

At our company we run a third-party Java-based GUI application on one of our Linux server machine, displaying the application to our local Windows work stations using the Cygwin X Server.

We noticed a few problems with a new version of this application and was able to narrow it down to the following conditions:
1. Java Swing application running on a UNIX host;
2. Java used is 1.6 (problem not noticed when using Java 1.5)
3. Displaying to Cygwin X server (I've heard other windows-based X servers have the same issue, but I don't have access to any others at this time).

If we run the application natively on Windows, we don't have any problems.
I'm told if the application runs on the Linux host and displays natively to that machine's display there are no problems (although I'm not able to verify this myself).

The problems are:

1. Any new frame/dialog is opened in the geographic center of the dual displays, rather than in the middle of one or the other;
2. Any attempt to drag the window to a different location on the display seems to work, but as soon as you let go of the drag, the window snaps back to the original location. This only happens the first time you try to move each window.
3. Drop-down controls (JComboBox, for example) just close back up as soon as you click on them. If you click and drag the mouse to attempt to make a selection, no selection can be made.

Are these known problems using 1.6 on UNIX displaying to Windows-based X Servers?

The only real problem is number 3. I expect that if I put more work into the window placement, I should be able to get past number 1. Number 2 is just a minor annoyance.

Any ideas how to get around this?

The following is a simple Java Swing application which when run in the correct environment will exhibit the problems.

import java.awt.EventQueue; import java.awt.GridBagConstraints; import java.awt.GridBagLayout; import java.awt.Insets; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import javax.swing.JButton; import javax.swing.JComboBox; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.JTextArea; /** * * This is a sample Java Swing application. * * @author HansenM2 * */ public class SwingSample { private static JFrame theFrame; private static String [] comboEntries = {"Option 1", "Option 2", "Option 3"}; public SwingSample() { theFrame = new JFrame("Swing Sample"); theFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE ); JPanel mainPanel = new JPanel(new GridBagLayout()); JTextArea notice = new JTextArea(); notice.setOpaque( false ); notice.setText("This is a sample Swing application"); mainPanel.add( notice, new GridBagConstraints(0, 0, 2, 1, 1.0, 1.0, GridBagConstraints.FIRST_LINE_START, GridBagConstraints.HORIZONTAL, new Insets(10, 5, 10, 5), 0, 0) ); JComboBox actionCB = new JComboBox(comboEntries); actionCB.setSelectedIndex( 0 ); mainPanel.add(actionCB, new GridBagConstraints(0, 1, 1, 1, 1.0, 1.0, GridBagConstraints.FIRST_LINE_START, GridBagConstraints.NONE, new Insets(0, 5, 10, 0), 0, 0)); JButton exitButton = new JButton("Exit"); mainPanel.add(exitButton, new GridBagConstraints(1, 1, 1, 1, 1.0, 1.0, GridBagConstraints.FIRST_LINE_END, GridBagConstraints.NONE, new Insets(0, 0, 10, 5), 0, 0)); theFrame.setContentPane(mainPanel); theFrame.pack(); theFrame.setLocationRelativeTo(null); theFrame.setVisible(true); exitButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { System.exit(0); } }); actionCB.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { JComboBox cb = (JComboBox)e.getSource(); System.out.println("Selected action: " + cb.getSelectedItem()); } }); } // constructor /** * Description of main. * * @param args */ public static void main ( String[] args ) { EventQueue.invokeLater( new Runnable() { public void run () { new SwingSample(); } } ); } }

Very cool, Peter. Of course, this will require a comment so future readers understand what was intended, but it will be less that what I was doing originally.

Thanks!

Well, with the help of a co-worker, I found a way to make this work, and it's not too painful:
<?xml version="1.0"?> <project name="Mark's test script" basedir="." default="all"> <!-- This is a sample file to show how to use an environment variable as the value for a build property, and use a default value if the environment variable is not set. In this case, the environment variable is ENV_VAR and the build property will be my.dir. If the environment variable is not set, then we want to use "/my/default/lib" as the default. --> <property environment="env"/> <target name="checkEdiDir"> <condition property="ediDirIsSet" value="true" > <isset property="env.ENV_VAR"/> </condition> </target> <target name="-varSet" depends="checkEdiDir" if="ediDirIsSet"> <!-- ENV_VAR set, use that value --> <property name="my.dir" value="${env.ENV_VAR}"/> </target> <target name="-varNotSet" depends="checkEdiDir" unless="ediDirIsSet"> <!-- ENV_VAR not set, use a default value --> <property name="my.dir" value="/my/default/lib"/> </target> <target name="all" depends="-varSet,-varNotSet" > <echo>This is my "all" target</echo> <echo>my.dir=${my.dir}</echo> </target> </project>
ENV_VAR=D:/foo/bar ant, results in the value "D:/foo/bar" being used.
ant by itself results in "/my/default/lib" being used.

Thanks,