Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#83 Fix for BUG 585726

closed-fixed
Andy Stevens
webdoclet (6)
5
2002-07-25
2002-07-25
William Ferguson
No

Ensures that web deployment descriptor session-
timeout element is only produced if that attribute is set.

The session-timeout currently gets output for all cases
except when it is zero. This would pose a problem if you
actaully needed to specify a zero session-timeout.

Discussion

  • Stops session-timeout being produced unless it is specified

     
    Attachments
  • Andy Stevens
    Andy Stevens
    2002-07-25

    • summary: Fix for BUG 585728 --> Fix for BUG 585726
     
  • Andy Stevens
    Andy Stevens
    2002-07-25

    Logged In: YES
    user_id=247081

    Doesn't work. Even if you don't include a parameter for the
    timeout in your <deploymentdescriptor>, ifHasConfigParam
    still sees the subtask's default value of 0.

    Try it on the samples - their build file doesn't set a session
    timeout, but with your patch applied there's still a <session-
    config> section in the resulting web.xml, which is bug 585726
    all over again...

     
  • Andy Stevens
    Andy Stevens
    2002-07-25

    Logged In: YES
    user_id=247081

    /s/585726/582804

    With a small tweak to WebXmlSubTask (change int to Integer
    as the type of the sessiontimeout field) it appears to be
    working as expected. I'll commit the changes later today.

     
  • Andy Stevens
    Andy Stevens
    2002-07-25

    Logged In: YES
    user_id=247081

    /s/585726/582804

    With a small tweak to WebXmlSubTask (change int to Integer
    as the type of the sessiontimeout field) it appears to be
    working as expected. I'll commit the changes later today.

     
  • Andy Stevens
    Andy Stevens
    2002-07-25

    • assigned_to: nobody --> stevensa
    • status: open --> closed-fixed
     
  • Andy Stevens
    Andy Stevens
    2002-07-25

    Logged In: YES
    user_id=247081

    Now applied.
    BTW, in the future it's probably better to just upload fixes
    on the relevant bug item (saves having to keep track of it in
    two separate places).

     
  • Logged In: YES
    user_id=558701

    Thanks Steven,

    this seems a good approach to me.
    Wrt uploading patches, do you mean just attaching the patch
    to the bug item instead of creating a patch item?

    What's the procedure wrt to setting/updating the status of
    bugs, ie who's responsible? And how do you ensure that
    you're patches get committed?

     
  • Andy Stevens
    Andy Stevens
    2002-07-28

    Logged In: YES
    user_id=247081

    >Thanks Steven,

    Andrew, actually, but you're welcome anyway.

    >Wrt uploading patches, do you mean just attaching the
    >patch to the bug item instead of creating a patch item?

    Exactly. The others may disagree, of course, but IMO
    keeping them together by attaching the patch to the bug
    report itself makes it easier to track.

    >What's the procedure wrt to setting/updating the status
    >of bugs, ie who's responsible?

    Whoever deals with it. Generally, we'd set the resolved
    field accordingly, but leave the items open till the
    subsequent release (so people can see what's already
    been fixed in the current version). However, the list was
    getting so long (and the 1.2 beta is hopefully near enough)
    that we've started closing them off.

    >And how do you ensure that
    >you're patches get committed?

    So long as they're in the trackers, we'll get to them
    eventually. It just depends on how busy the various
    developers are. Plus, depending on which module
    fixes/patches are for, they may get left to the developer
    who originally wrote the module.

    NB This isn't really the best place for general discussion,
    the mailing lists would be more appropriate.