Nabble - JspWiki - User

JSPWiki 2.8.3

2009-11-17T12:40:46Z

Folks,

we just rolled a new release of JSPWiki 2.8.3, available from the
usual location at http://www.jspwiki.org/wiki/JSPWikiDownload/

JSPWiki 2.8.3 is a security and stability update to 2.8.x-series. All
users
are encouraged to upgrade.

The full log of any issues fixed can be found at:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310732&fixfor=12313766

This is the first major version of JSPWiki which is released
completely under
the Apache License. This is done as a part of the transition to the
Apache Incubation.

However, this is NOT an Apache release - JSPWiki 3.0 will be the first
official Apache release.

Please report any issues at https://issues.apache.org/jira/browse/JSPWIKI

UPDATES SINCE 2.8.2
===================

The full list is available in the ChangeLog file. Highlights include

* Improved logging

* JDK6 compilation support

* Brazilian Portuguese translation, thanks to Paulo Amaral

* Addition of new PageViewPlugin

* Numerous bugfixes, esp. in sorting.

Looking for right-to-left guinea pigs

2009-11-15T13:14:54Z

[apologies for cross-posting; please respond only to the mailing list
in which you are a member, and if both, please post to jspwiki-dev]

Hello. The developer group recently learned that JSPWiki was passed up
by Sun Microsystems' OpenSolaris community wiki due to a number of
putative failings. One of these is a lack of support for right-to-left
(RTL) text, such as Arabic, Hebrew, Punjabi, or Kashmiri. We'd like to
remedy that, but need some help, as none of our developers speak or
write an RTL language (to my knowledge).

If you or your organisation's wiki are currently using a right-to-left
script and are willing to provide us with feedback on any failings in
JSPWiki's implementation, we'd be very happy to work with you on fixing
those bugs. It would benefit the JSPWiki community as well as improving
JSPWiki's support for your language. You can help contribute to world
happiness.

If you'd prefer not to provide that help on the public mailing list,
you can also contact me directly at: murray09 at altheim dot com.

Thanks much for any help,

Murray

...........................................................................
Murray Altheim <murray09 at altheim dot com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =

Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record

RE: ACL questions

2009-10-27T17:46:19Z

Workaround I would use for this (Dirty way, of course..):
[{ALLOW upload Familie}]

-----Original Message-----
From: Harry Metske [mailto:harry.metske@...]
Sent: Tuesday, 27 October 2009 5:42 AM
To: jspwiki-user@...
Subject: Re: ACL questions

Harald,

are you sure this is not a browser caching issue, this problem has been
reported before : https://issues.apache.org/jira/browse/JSPWIKI-361

Also, can you reproduce the problem on http://sandbox.jspwiki.org ?

regards,
Harry

2009/10/26 Harald Krammer <Harald.Krammer@...>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello,
> I am again. I played around with the permission concept e.g. [{ALLOW
> edit harald}] and following questions are unclear for me.
>
> *) When I set page permissions, attachments are not
> considered. e.g. I made a side with permissions
> [{ALLOW edit hk}] and [{ALLOW view Familie}] on side
> https://xen.hkr.at/wiki/Wiki.jsp?page=secret
> Permissions are fine, but a direct link to attachments on side secrete
> works without any restrictions.
> e.g.: https://xen.hkr.at/wiki/attach/Secret/non-public.txt
>
> Is that a limitation, a known issue, a bug or a wrong user usage?
>
> *) Exits an overview plug-in about permissions of all sides?
> Currently I do it around with a shell script. I know it's the wrong way,
> but easy for me to check permissions problems.
>
> *) Usage of if-plugin
>
> Currently I use the ifplugin, because it's easy to use. Exits a way to
> disable 'view page source' for e.g. non authenticated users?
>
>
> Nice greetings,
> Harald
>
>
> - --
>
> Harald Krammer
> Brucknerstrasse 33
> A - 4020 Linz
> AUSTRIA
>
> Mobil +43.(0) 664. 130 59 58
> Mail: Harald.Krammer (at) hkr.at
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREIAAYFAkrl60oACgkQ9QlAsubHO9tZdACg4iRRAaXN82thHPc5tClLah4b
> QIAAni+/qATdb9f66KpAaIZ7Wkh079EQ
> =J6Cn
> -----END PGP SIGNATURE-----
>

Re: ACL questions

2009-10-26T12:19:08Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Harry,
you are right. It's a browser issue.

When I clear the cache by hand in my browser then it works as expected.
Strange... The refresh button did not work....

Here a few parts in the http-header:
If-Modified-Since: Mon, 26 Oct 2009 17:40:29 GMT
Cache-Control:max-age=0

If I can trust firebug then every refresh increases the cache expires
time!? ( I use firefox 3.0)

Nice greetings,
Harald

Harry Metske schrieb:

> Harald,
>
> are you sure this is not a browser caching issue, this problem has been
> reported before : https://issues.apache.org/jira/browse/JSPWIKI-361
>
> Also, can you reproduce the problem on http://sandbox.jspwiki.org ?
>
> regards,
> Harry
>
> 2009/10/26 Harald Krammer <Harald.Krammer@...>
>
> Hello,
> I am again. I played around with the permission concept e.g. [{ALLOW
> edit harald}] and following questions are unclear for me.
>
> *) When I set page permissions, attachments are not
> considered. e.g. I made a side with permissions
> [{ALLOW edit hk}] and [{ALLOW view Familie}] on side
> https://xen.hkr.at/wiki/Wiki.jsp?page=secret
> Permissions are fine, but a direct link to attachments on side secrete
> works without any restrictions.
> e.g.: https://xen.hkr.at/wiki/attach/Secret/non-public.txt
>
> Is that a limitation, a known issue, a bug or a wrong user usage?
>
> *) Exits an overview plug-in about permissions of all sides?
> Currently I do it around with a shell script. I know it's the wrong way,
> but easy for me to check permissions problems.
>
> *) Usage of if-plugin
>
> Currently I use the ifplugin, because it's easy to use. Exits a way to
> disable 'view page source' for e.g. non authenticated users?
>
>
> Nice greetings,
> Harald
>
>
>>

- --

Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA

Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkrl9icACgkQ9QlAsubHO9td+ACfWrhnEvxa7YAqdRZrjZYteaKD
xOwAn1QANqIE3dy07a0f8/jpbCNgIDg1
=EY8Z
-----END PGP SIGNATURE-----

Re: ACL questions

2009-10-26T11:42:18Z

Harald,

are you sure this is not a browser caching issue, this problem has been
reported before : https://issues.apache.org/jira/browse/JSPWIKI-361

Also, can you reproduce the problem on http://sandbox.jspwiki.org ?

regards,
Harry

2009/10/26 Harald Krammer <Harald.Krammer@...>

ACL questions

2009-10-26T11:32:52Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,
I am again. I played around with the permission concept e.g. [{ALLOW
edit harald}] and following questions are unclear for me.

*) When I set page permissions, attachments are not
considered. e.g. I made a side with permissions
[{ALLOW edit hk}] and [{ALLOW view Familie}] on side
https://xen.hkr.at/wiki/Wiki.jsp?page=secret
Permissions are fine, but a direct link to attachments on side secrete
works without any restrictions.
e.g.: https://xen.hkr.at/wiki/attach/Secret/non-public.txt

Is that a limitation, a known issue, a bug or a wrong user usage?

*) Exits an overview plug-in about permissions of all sides?
Currently I do it around with a shell script. I know it's the wrong way,
but easy for me to check permissions problems.

*) Usage of if-plugin

Currently I use the ifplugin, because it's easy to use. Exits a way to
disable 'view page source' for e.g. non authenticated users?

Nice greetings,
Harald

- --

Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA

Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkrl60oACgkQ9QlAsubHO9tZdACg4iRRAaXN82thHPc5tClLah4b
QIAAni+/qATdb9f66KpAaIZ7Wkh079EQ
=J6Cn
-----END PGP SIGNATURE-----

Re: Visual LDAP user name

2009-10-25T04:15:00Z

...you check out the trunk and look at the javadocs, which are
extremely well-documented.

Sorry my reply came as a serialization... I did it one-handed on the
iPhone and fat-fingered TWICE.

Andrew

On Oct 25, 2009, at 7:10, Andrew Jaquith <andrew.r.jaquith@...>
wrote:

> Sorry-- I fat-fingered the send button!
>
> Anyhow, with the LdapUserDatabase you won't need to provision or
> deprovision because everything will be in LDAP. We will keep some
> data locally (user prefs) but that's it.
>
> At this point, if you still have concerns I'd recommend yo
>
> On Oct 25, 2009, at 7:04, Andrew Jaquith
> <andrew.r.jaquith@...> wrote:
>
>> I should not have used the magic word "provision" in my last post.
>> The important concept is that when the LdapUserDatabase is used,
>> LDAP *is* the user database
>>
>> On Oct 25, 2009, at 6:38, Jim Willeke <jim@...> wrote:
>>
>>> But what about de-provisioning users?
>>>
>>> The issue with putting users in yet another database in the
>>> enterprise world
>>> central provisioning, de-provisioning and RBAC are the strategic
>>> directions
>>> with no desire to mange users in remote stores.
>>>
>>> And why would someone want to put in information into the WIKI
>>> when it is
>>> already been add to the user in LDAP via the enterprise portal?
>>>
>>> I will agree the local "groups" concept is necessary, but it
>>> should be an
>>> agumnetation to container managed security that most enterprises
>>> would
>>> utilize.
>>>
>>> So users in the role (perhaps by department) "Sales" would always
>>> be able to
>>> view any pages with "Sales":
>>>
>>> Then the local "groups" would be done to perform "teaming"
>>> arrangements as
>>> would be done in a project that would cross departmental lines.
>>>
>>> -jim
>>> Jim Willeke
>>>
>>>
>>> On Sat, Oct 24, 2009 at 11:12 AM, Andrew Jaquith <andrew.r.jaquith@...
>>>> wrote:
>>>
>>>> JSPWiki 3.0 trunk already has an LdapUserDatabase and
>>>> LdapAuthorizer,
>>>> which means that it can obtain user profiles on a read-only basis
>>>> from
>>>> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your
>>>> users will be "provisioned" in JSPWiki automatically. This should
>>>> solve the user-experience problem you described.
>>>>
>>>> The upcoming 3.0 LDAP features have been developed and tested with
>>>> Active Directory and OpenLDAP. It is configured via the GUI at
>>>> install-time.
>>>>
>>>> With respect to permissions and group memberships: these are good
>>>> suggestions. We still have some work to do for the GUI for ACLs for
>>>> 3.0. I agree that we should be validating user names when users
>>>> create
>>>> the ACLs. Same for adding users to groups. These suggestions will
>>>> be
>>>> incorporated into how the ACL GUIs work -- likely via AJAX in
>>>> real-time.
>>>>
>>>> Andrew
>>>>
>>>> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt
>>>> <te@...> wrote:
>>>>> The group and permission system in the jspwiki is rather
>>>>> dynamic, and
>>>> ldaps
>>>>> tends to be readonly except for a groups of administrators.
>>>>> There for
>>>> there
>>>>> is still need for the user.xml and group.xml. But in my opinion
>>>>> the
>>>> user.xml
>>>>> needs to be automatically updated when a new ldap user is logged
>>>>> in.
>>>>>
>>>>> Otherwise granting and managing jspwiki permissions i a
>>>>> nightmare, this
>>>> also
>>>>> enhanced since there is no check on if a user exist - when
>>>>> adding users
>>>> to
>>>>> wiki group or setting a page permission.
>>>>>
>>>>> I think the following should be changed.
>>>>>
>>>>> - First time a new user is logged in - the user should be added
>>>>> to the
>>>> the
>>>>> user.xml and redirect to the profile page for setting additional
>>>> information
>>>>> (email, full name and section edition etc)
>>>>>
>>>>> - Adding page permission should lookup if the group or the user
>>>>> exist.
>>>>>
>>>>> - Adding users to a wiki group should only be possible for
>>>>> existing
>>>> users.
>>>>>
>>>>> /Thomas
>>>>>
>>>>>
>>>>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote:
>>>>>
>>>>>> Why allow people to eliminate the user.xml?
>>>>>>
>>>>>> Why not allow the use of LDAP for the user profile?
>>>>>>
>>>>>> Allow mapping the LDAP attributes to the profile values?
>>>>>>
>>>>>> Enterprises have no desire to maintain another separate user
>>>>>> store of
>>>>>> information. Many already have a central LDAP store.
>>>>>>
>>>>>> -jim
>>>>>> Jim Willeke
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt
>>>>>> <te@...>
>>>> wrote:
>>>>>>
>>>>>>> I would suggest a change, if a ldap user is logging the first
>>>>>>> time.
>>>> the
>>>>>>> Wiki should create the user in the user.xml - it gives a lot
>>>>>>> of problem
>>>>>>> when
>>>>>>> adding a ldap user to a wiki group, since it possible that the
>>>>>>> user
>>>> isn't
>>>>>>> created.
>>>>>>>
>>>>>>>
>>>>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
>>>>>>>
>>>>>>> If a user creates a user profile after logging into the
>>>>>>> container, he
>>>> or
>>>>>>>>
>>>>>>>> she will have an opportunity to specify a "full name." If a
>>>>>>>> full name
>>>> is
>>>>>>>> supplied, it will be used in page histories etc from that point
>>>> forward.
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...
>>>>>>>> >
>>>> wrote:
>>>>>>>>
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>
>>>>>>>>> Hash: SHA256
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>> I run JSPWiki with Web Container Authentication via LDAP and
>>>>>>>>> it runs
>>>>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK
>>>>>>>>> 6).
>>>>>>>>>
>>>>>>>>> Only the visualization of real user name is still missing. I
>>>>>>>>> get only
>>>>>>>>> the login name (short name) instead of the full name in the
>>>>>>>>> change
>>>>>>>>> history and so on. Is it a default behaviour or
>>>>>>>>> misconfiguration?
>>>>>>>>>
>>>>>>>>> Nice greetings,
>>>>>>>>> Harald
>>>>>>>>>
>>>>>>>>> - --
>>>>>>>>>
>>>>>>>>> Harald Krammer
>>>>>>>>> Brucknerstrasse 33
>>>>>>>>> A - 4020 Linz
>>>>>>>>> AUSTRIA
>>>>>>>>>
>>>>>>>>> Mobil +43.(0) 664. 130 59 58
>>>>>>>>> Mail: Harald.Krammer (at) hkr.at
>>>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>>>>>
>>>>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/
>>>>>>>>> HrqMiWfZ
>>>>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>>>>>>>>> =Kd7Y
>>>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>

Re: Visual LDAP user name

2009-10-25T04:10:36Z

Sorry-- I fat-fingered the send button!

Anyhow, with the LdapUserDatabase you won't need to provision or
deprovision because everything will be in LDAP. We will keep some data
locally (user prefs) but that's it.

At this point, if you still have concerns I'd recommend yo

On Oct 25, 2009, at 7:04, Andrew Jaquith <andrew.r.jaquith@...>
wrote:

> I should not have used the magic word "provision" in my last post.
> The important concept is that when the LdapUserDatabase is used,
> LDAP *is* the user database
>
> On Oct 25, 2009, at 6:38, Jim Willeke <jim@...> wrote:
>
>> But what about de-provisioning users?
>>
>> The issue with putting users in yet another database in the
>> enterprise world
>> central provisioning, de-provisioning and RBAC are the strategic
>> directions
>> with no desire to mange users in remote stores.
>>
>> And why would someone want to put in information into the WIKI when
>> it is
>> already been add to the user in LDAP via the enterprise portal?
>>
>> I will agree the local "groups" concept is necessary, but it should
>> be an
>> agumnetation to container managed security that most enterprises
>> would
>> utilize.
>>
>> So users in the role (perhaps by department) "Sales" would always
>> be able to
>> view any pages with "Sales":
>>
>> Then the local "groups" would be done to perform "teaming"
>> arrangements as
>> would be done in a project that would cross departmental lines.
>>
>> -jim
>> Jim Willeke
>>
>>
>> On Sat, Oct 24, 2009 at 11:12 AM, Andrew Jaquith <andrew.r.jaquith@...
>>> wrote:
>>
>>> JSPWiki 3.0 trunk already has an LdapUserDatabase and
>>> LdapAuthorizer,
>>> which means that it can obtain user profiles on a read-only basis
>>> from
>>> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your
>>> users will be "provisioned" in JSPWiki automatically. This should
>>> solve the user-experience problem you described.
>>>
>>> The upcoming 3.0 LDAP features have been developed and tested with
>>> Active Directory and OpenLDAP. It is configured via the GUI at
>>> install-time.
>>>
>>> With respect to permissions and group memberships: these are good
>>> suggestions. We still have some work to do for the GUI for ACLs for
>>> 3.0. I agree that we should be validating user names when users
>>> create
>>> the ACLs. Same for adding users to groups. These suggestions will be
>>> incorporated into how the ACL GUIs work -- likely via AJAX in
>>> real-time.
>>>
>>> Andrew
>>>
>>> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@...>
>>> wrote:
>>>> The group and permission system in the jspwiki is rather dynamic,
>>>> and
>>> ldaps
>>>> tends to be readonly except for a groups of administrators. There
>>>> for
>>> there
>>>> is still need for the user.xml and group.xml. But in my opinion the
>>> user.xml
>>>> needs to be automatically updated when a new ldap user is logged
>>>> in.
>>>>
>>>> Otherwise granting and managing jspwiki permissions i a
>>>> nightmare, this
>>> also
>>>> enhanced since there is no check on if a user exist - when adding
>>>> users
>>> to
>>>> wiki group or setting a page permission.
>>>>
>>>> I think the following should be changed.
>>>>
>>>> - First time a new user is logged in - the user should be added
>>>> to the
>>> the
>>>> user.xml and redirect to the profile page for setting additional
>>> information
>>>> (email, full name and section edition etc)
>>>>
>>>> - Adding page permission should lookup if the group or the user
>>>> exist.
>>>>
>>>> - Adding users to a wiki group should only be possible for existing
>>> users.
>>>>
>>>> /Thomas
>>>>
>>>>
>>>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote:
>>>>
>>>>> Why allow people to eliminate the user.xml?
>>>>>
>>>>> Why not allow the use of LDAP for the user profile?
>>>>>
>>>>> Allow mapping the LDAP attributes to the profile values?
>>>>>
>>>>> Enterprises have no desire to maintain another separate user
>>>>> store of
>>>>> information. Many already have a central LDAP store.
>>>>>
>>>>> -jim
>>>>> Jim Willeke
>>>>>
>>>>>
>>>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@...>
>>> wrote:
>>>>>
>>>>>> I would suggest a change, if a ldap user is logging the first
>>>>>> time.
>>> the
>>>>>> Wiki should create the user in the user.xml - it gives a lot of
>>>>>> problem
>>>>>> when
>>>>>> adding a ldap user to a wiki group, since it possible that the
>>>>>> user
>>> isn't
>>>>>> created.
>>>>>>
>>>>>>
>>>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
>>>>>>
>>>>>> If a user creates a user profile after logging into the
>>>>>> container, he
>>> or
>>>>>>>
>>>>>>> she will have an opportunity to specify a "full name." If a
>>>>>>> full name
>>> is
>>>>>>> supplied, it will be used in page histories etc from that point
>>> forward.
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> On Oct 22, 2009, at 16:34, Harald Krammer
>>>>>>> <Harald.Krammer@...>
>>> wrote:
>>>>>>>
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>
>>>>>>>> Hash: SHA256
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>> I run JSPWiki with Web Container Authentication via LDAP and
>>>>>>>> it runs
>>>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK
>>>>>>>> 6).
>>>>>>>>
>>>>>>>> Only the visualization of real user name is still missing. I
>>>>>>>> get only
>>>>>>>> the login name (short name) instead of the full name in the
>>>>>>>> change
>>>>>>>> history and so on. Is it a default behaviour or
>>>>>>>> misconfiguration?
>>>>>>>>
>>>>>>>> Nice greetings,
>>>>>>>> Harald
>>>>>>>>
>>>>>>>> - --
>>>>>>>>
>>>>>>>> Harald Krammer
>>>>>>>> Brucknerstrasse 33
>>>>>>>> A - 4020 Linz
>>>>>>>> AUSTRIA
>>>>>>>>
>>>>>>>> Mobil +43.(0) 664. 130 59 58
>>>>>>>> Mail: Harald.Krammer (at) hkr.at
>>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>>>>
>>>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/
>>>>>>>> HrqMiWfZ
>>>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>>>>>>>> =Kd7Y
>>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>

Re: Visual LDAP user name

2009-10-25T04:04:51Z

I should not have used the magic word "provision" in my last post. The
important concept is that when the LdapUserDatabase is used, LDAP *is*
the user database

On Oct 25, 2009, at 6:38, Jim Willeke <jim@...> wrote:

> But what about de-provisioning users?
>
> The issue with putting users in yet another database in the
> enterprise world
> central provisioning, de-provisioning and RBAC are the strategic
> directions
> with no desire to mange users in remote stores.
>
> And why would someone want to put in information into the WIKI when
> it is
> already been add to the user in LDAP via the enterprise portal?
>
> I will agree the local "groups" concept is necessary, but it should
> be an
> agumnetation to container managed security that most enterprises would
> utilize.
>
> So users in the role (perhaps by department) "Sales" would always be
> able to
> view any pages with "Sales":
>
> Then the local "groups" would be done to perform "teaming"
> arrangements as
> would be done in a project that would cross departmental lines.
>
> -jim
> Jim Willeke
>
>
> On Sat, Oct 24, 2009 at 11:12 AM, Andrew Jaquith <andrew.r.jaquith@...
>> wrote:
>
>> JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer,
>> which means that it can obtain user profiles on a read-only basis
>> from
>> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your
>> users will be "provisioned" in JSPWiki automatically. This should
>> solve the user-experience problem you described.
>>
>> The upcoming 3.0 LDAP features have been developed and tested with
>> Active Directory and OpenLDAP. It is configured via the GUI at
>> install-time.
>>
>> With respect to permissions and group memberships: these are good
>> suggestions. We still have some work to do for the GUI for ACLs for
>> 3.0. I agree that we should be validating user names when users
>> create
>> the ACLs. Same for adding users to groups. These suggestions will be
>> incorporated into how the ACL GUIs work -- likely via AJAX in
>> real-time.
>>
>> Andrew
>>
>> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@...>
>> wrote:
>>> The group and permission system in the jspwiki is rather dynamic,
>>> and
>> ldaps
>>> tends to be readonly except for a groups of administrators. There
>>> for
>> there
>>> is still need for the user.xml and group.xml. But in my opinion the
>> user.xml
>>> needs to be automatically updated when a new ldap user is logged in.
>>>
>>> Otherwise granting and managing jspwiki permissions i a nightmare,
>>> this
>> also
>>> enhanced since there is no check on if a user exist - when adding
>>> users
>> to
>>> wiki group or setting a page permission.
>>>
>>> I think the following should be changed.
>>>
>>> - First time a new user is logged in - the user should be added to
>>> the
>> the
>>> user.xml and redirect to the profile page for setting additional
>> information
>>> (email, full name and section edition etc)
>>>
>>> - Adding page permission should lookup if the group or the user
>>> exist.
>>>
>>> - Adding users to a wiki group should only be possible for existing
>> users.
>>>
>>> /Thomas
>>>
>>>
>>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote:
>>>
>>>> Why allow people to eliminate the user.xml?
>>>>
>>>> Why not allow the use of LDAP for the user profile?
>>>>
>>>> Allow mapping the LDAP attributes to the profile values?
>>>>
>>>> Enterprises have no desire to maintain another separate user
>>>> store of
>>>> information. Many already have a central LDAP store.
>>>>
>>>> -jim
>>>> Jim Willeke
>>>>
>>>>
>>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@...>
>> wrote:
>>>>
>>>>> I would suggest a change, if a ldap user is logging the first
>>>>> time.
>> the
>>>>> Wiki should create the user in the user.xml - it gives a lot of
>>>>> problem
>>>>> when
>>>>> adding a ldap user to a wiki group, since it possible that the
>>>>> user
>> isn't
>>>>> created.
>>>>>
>>>>>
>>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
>>>>>
>>>>> If a user creates a user profile after logging into the
>>>>> container, he
>> or
>>>>>>
>>>>>> she will have an opportunity to specify a "full name." If a
>>>>>> full name
>> is
>>>>>> supplied, it will be used in page histories etc from that point
>> forward.
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...>
>> wrote:
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>
>>>>>>> Hash: SHA256
>>>>>>>
>>>>>>> Hello,
>>>>>>> I run JSPWiki with Web Container Authentication via LDAP and
>>>>>>> it runs
>>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
>>>>>>>
>>>>>>> Only the visualization of real user name is still missing. I
>>>>>>> get only
>>>>>>> the login name (short name) instead of the full name in the
>>>>>>> change
>>>>>>> history and so on. Is it a default behaviour or
>>>>>>> misconfiguration?
>>>>>>>
>>>>>>> Nice greetings,
>>>>>>> Harald
>>>>>>>
>>>>>>> - --
>>>>>>>
>>>>>>> Harald Krammer
>>>>>>> Brucknerstrasse 33
>>>>>>> A - 4020 Linz
>>>>>>> AUSTRIA
>>>>>>>
>>>>>>> Mobil +43.(0) 664. 130 59 58
>>>>>>> Mail: Harald.Krammer (at) hkr.at
>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>>>
>>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
>>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>>>>>>> =Kd7Y
>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>

Re: Visual LDAP user name

2009-10-25T04:01:02Z

It is still too early. I don't have an estimate of when you can start
testing. We would Iike to get an alpha out soon, obviously.

On Oct 25, 2009, at 5:30, Harald Krammer <Harald.Krammer@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> That sounds interesting.
> It is noted that the trunk is heavily under construction and the
> code is
> broken. Does it make sense to test current trunk version or is it
> too early?
>
> Greetings,
> Harald
>
> Andrew Jaquith schrieb:
>> JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer,
>> which means that it can obtain user profiles on a read-only basis
>> from
>> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your
>> users will be "provisioned" in JSPWiki automatically. This should
>> solve the user-experience problem you described.
>>
>> The upcoming 3.0 LDAP features have been developed and tested with
>> Active Directory and OpenLDAP. It is configured via the GUI at
>> install-time.
>>
>> With respect to permissions and group memberships: these are good
>> suggestions. We still have some work to do for the GUI for ACLs for
>> 3.0. I agree that we should be validating user names when users
>> create
>> the ACLs. Same for adding users to groups. These suggestions will be
>> incorporated into how the ACL GUIs work -- likely via AJAX in
>> real-time.
>>
>> Andrew
>>
>> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@...>
>> wrote:
>>> The group and permission system in the jspwiki is rather dynamic,
>>> and ldaps
>>> tends to be readonly except for a groups of administrators. There
>>> for there
>>> is still need for the user.xml and group.xml. But in my opinion
>>> the user.xml
>>> needs to be automatically updated when a new ldap user is logged in.
>>>
>>> Otherwise granting and managing jspwiki permissions i a nightmare,
>>> this also
>>> enhanced since there is no check on if a user exist - when adding
>>> users to
>>> wiki group or setting a page permission.
>>>
>>> I think the following should be changed.
>>>
>>> - First time a new user is logged in - the user should be added to
>>> the the
>>> user.xml and redirect to the profile page for setting additional
>>> information
>>> (email, full name and section edition etc)
>>>
>>> - Adding page permission should lookup if the group or the user
>>> exist.
>>>
>>> - Adding users to a wiki group should only be possible for
>>> existing users.
>>>
>>> /Thomas
>>>
>>>
>>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote:
>>>
>>>> Why allow people to eliminate the user.xml?
>>>>
>>>> Why not allow the use of LDAP for the user profile?
>>>>
>>>> Allow mapping the LDAP attributes to the profile values?
>>>>
>>>> Enterprises have no desire to maintain another separate user
>>>> store of
>>>> information. Many already have a central LDAP store.
>>>>
>>>> -jim
>>>> Jim Willeke
>>>>
>>>>
>>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt
>>>> <te@...> wrote:
>>>>
>>>>> I would suggest a change, if a ldap user is logging the first
>>>>> time. the
>>>>> Wiki should create the user in the user.xml - it gives a lot of
>>>>> problem
>>>>> when
>>>>> adding a ldap user to a wiki group, since it possible that the
>>>>> user isn't
>>>>> created.
>>>>>
>>>>>
>>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
>>>>>
>>>>> If a user creates a user profile after logging into the
>>>>> container, he or
>>>>>> she will have an opportunity to specify a "full name." If a
>>>>>> full name is
>>>>>> supplied, it will be used in page histories etc from that point
>>>>>> forward.
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> On Oct 22, 2009, at 16:34, Harald Krammer
>>>>>> <Harald.Krammer@...> wrote:
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA256
>>>>>>>
>>>>>>> Hello,
>>>>>>> I run JSPWiki with Web Container Authentication via LDAP and
>>>>>>> it runs
>>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
>>>>>>>
>>>>>>> Only the visualization of real user name is still missing. I
>>>>>>> get only
>>>>>>> the login name (short name) instead of the full name in the
>>>>>>> change
>>>>>>> history and so on. Is it a default behaviour or
>>>>>>> misconfiguration?
>>>>>>>
>>>>>>> Nice greetings,
>>>>>>> Harald
>>>>>>>
>>>>>>> - --
>>>>>>>
>>>>>>> Harald Krammer
>>>>>>> Brucknerstrasse 33
>>>>>>> A - 4020 Linz
>>>>>>> AUSTRIA
>>>>>>>
>>>>>>> Mobil +43.(0) 664. 130 59 58
>>>>>>> Mail: Harald.Krammer (at) hkr.at
>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>>>
>>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
>>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>>>>>>> =Kd7Y
>>>>>>> -----END PGP SIGNATURE-----
>>>>>>>
>>>
>>
>
>
> - --
>
> Harald Krammer
> Brucknerstrasse 33
> A - 4020 Linz
> AUSTRIA
>
> Mobil +43.(0) 664. 130 59 58
> Mail: Harald.Krammer (at) hkr.at
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREIAAYFAkrkGqEACgkQ9QlAsubHO9vsYACgriH34OZiGCZq6Ac2DayNJnd3
> SKQAni/X1DtibeNEbZKtnzNAe+OHUwt2
> =KwyM
> -----END PGP SIGNATURE-----

Re: Visual LDAP user name

2009-10-25T03:38:10Z

But what about de-provisioning users?

The issue with putting users in yet another database in the enterprise world
central provisioning, de-provisioning and RBAC are the strategic directions
with no desire to mange users in remote stores.

And why would someone want to put in information into the WIKI when it is
already been add to the user in LDAP via the enterprise portal?

I will agree the local "groups" concept is necessary, but it should be an
agumnetation to container managed security that most enterprises would
utilize.

So users in the role (perhaps by department) "Sales" would always be able to
view any pages with "Sales":

Then the local "groups" would be done to perform "teaming" arrangements as
would be done in a project that would cross departmental lines.

-jim
Jim Willeke

On Sat, Oct 24, 2009 at 11:12 AM, Andrew Jaquith <andrew.r.jaquith@...
> wrote:

> JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer,
> which means that it can obtain user profiles on a read-only basis from
> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your
> users will be "provisioned" in JSPWiki automatically. This should
> solve the user-experience problem you described.
>
> The upcoming 3.0 LDAP features have been developed and tested with
> Active Directory and OpenLDAP. It is configured via the GUI at
> install-time.
>
> With respect to permissions and group memberships: these are good
> suggestions. We still have some work to do for the GUI for ACLs for
> 3.0. I agree that we should be validating user names when users create
> the ACLs. Same for adding users to groups. These suggestions will be
> incorporated into how the ACL GUIs work -- likely via AJAX in
> real-time.
>
> Andrew
>
> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@...> wrote:
> > The group and permission system in the jspwiki is rather dynamic, and
> ldaps
> > tends to be readonly except for a groups of administrators. There for
> there
> > is still need for the user.xml and group.xml. But in my opinion the
> user.xml
> > needs to be automatically updated when a new ldap user is logged in.
> >
> > Otherwise granting and managing jspwiki permissions i a nightmare, this
> also
> > enhanced since there is no check on if a user exist - when adding users
> to
> > wiki group or setting a page permission.
> >
> > I think the following should be changed.
> >
> > - First time a new user is logged in - the user should be added to the
> the
> > user.xml and redirect to the profile page for setting additional
> information
> > (email, full name and section edition etc)
> >
> > - Adding page permission should lookup if the group or the user exist.
> >
> > - Adding users to a wiki group should only be possible for existing
> users.
> >
> > /Thomas
> >
> >
> > On Oct 24, 2009, at 10:57 , Jim Willeke wrote:
> >
> >> Why allow people to eliminate the user.xml?
> >>
> >> Why not allow the use of LDAP for the user profile?
> >>
> >> Allow mapping the LDAP attributes to the profile values?
> >>
> >> Enterprises have no desire to maintain another separate user store of
> >> information. Many already have a central LDAP store.
> >>
> >> -jim
> >> Jim Willeke
> >>
> >>
> >> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@...>
> wrote:
> >>
> >>> I would suggest a change, if a ldap user is logging the first time.
> the
> >>> Wiki should create the user in the user.xml - it gives a lot of problem
> >>> when
> >>> adding a ldap user to a wiki group, since it possible that the user
> isn't
> >>> created.
> >>>
> >>>
> >>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
> >>>
> >>> If a user creates a user profile after logging into the container, he
> or
> >>>>
> >>>> she will have an opportunity to specify a "full name." If a full name
> is
> >>>> supplied, it will be used in page histories etc from that point
> forward.
> >>>>
> >>>> Andrew
> >>>>
> >>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...>
> wrote:
> >>>>
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>
> >>>>> Hash: SHA256
> >>>>>
> >>>>> Hello,
> >>>>> I run JSPWiki with Web Container Authentication via LDAP and it runs
> >>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
> >>>>>
> >>>>> Only the visualization of real user name is still missing. I get only
> >>>>> the login name (short name) instead of the full name in the change
> >>>>> history and so on. Is it a default behaviour or misconfiguration?
> >>>>>
> >>>>> Nice greetings,
> >>>>> Harald
> >>>>>
> >>>>> - --
> >>>>>
> >>>>> Harald Krammer
> >>>>> Brucknerstrasse 33
> >>>>> A - 4020 Linz
> >>>>> AUSTRIA
> >>>>>
> >>>>> Mobil +43.(0) 664. 130 59 58
> >>>>> Mail: Harald.Krammer (at) hkr.at
> >>>>> -----BEGIN PGP SIGNATURE-----
> >>>>> Version: GnuPG v1.4.9 (GNU/Linux)
> >>>>>
> >>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
> >>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
> >>>>> =Kd7Y
> >>>>> -----END PGP SIGNATURE-----
> >>>>>
> >>>>
> >>>
> >
> >
>

Re: Visual LDAP user name

2009-10-25T02:30:19Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

That sounds interesting.
It is noted that the trunk is heavily under construction and the code is
broken. Does it make sense to test current trunk version or is it too early?

Greetings,
Harald

Andrew Jaquith schrieb:

> JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer,
> which means that it can obtain user profiles on a read-only basis from
> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your
> users will be "provisioned" in JSPWiki automatically. This should
> solve the user-experience problem you described.
>
> The upcoming 3.0 LDAP features have been developed and tested with
> Active Directory and OpenLDAP. It is configured via the GUI at
> install-time.
>
> With respect to permissions and group memberships: these are good
> suggestions. We still have some work to do for the GUI for ACLs for
> 3.0. I agree that we should be validating user names when users create
> the ACLs. Same for adding users to groups. These suggestions will be
> incorporated into how the ACL GUIs work -- likely via AJAX in
> real-time.
>
> Andrew
>
> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@...> wrote:
>> The group and permission system in the jspwiki is rather dynamic, and ldaps
>> tends to be readonly except for a groups of administrators. There for there
>> is still need for the user.xml and group.xml. But in my opinion the user.xml
>> needs to be automatically updated when a new ldap user is logged in.
>>
>> Otherwise granting and managing jspwiki permissions i a nightmare, this also
>> enhanced since there is no check on if a user exist - when adding users to
>> wiki group or setting a page permission.
>>
>> I think the following should be changed.
>>
>> - First time a new user is logged in - the user should be added to the the
>> user.xml and redirect to the profile page for setting additional information
>> (email, full name and section edition etc)
>>
>> - Adding page permission should lookup if the group or the user exist.
>>
>> - Adding users to a wiki group should only be possible for existing users.
>>
>> /Thomas
>>
>>
>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote:
>>
>>> Why allow people to eliminate the user.xml?
>>>
>>> Why not allow the use of LDAP for the user profile?
>>>
>>> Allow mapping the LDAP attributes to the profile values?
>>>
>>> Enterprises have no desire to maintain another separate user store of
>>> information. Many already have a central LDAP store.
>>>
>>> -jim
>>> Jim Willeke
>>>
>>>
>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@...> wrote:
>>>
>>>> I would suggest a change, if a ldap user is logging the first time. the
>>>> Wiki should create the user in the user.xml - it gives a lot of problem
>>>> when
>>>> adding a ldap user to a wiki group, since it possible that the user isn't
>>>> created.
>>>>
>>>>
>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
>>>>
>>>> If a user creates a user profile after logging into the container, he or
>>>>> she will have an opportunity to specify a "full name." If a full name is
>>>>> supplied, it will be used in page histories etc from that point forward.
>>>>>
>>>>> Andrew
>>>>>
>>>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...> wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA256
>>>>>>
>>>>>> Hello,
>>>>>> I run JSPWiki with Web Container Authentication via LDAP and it runs
>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
>>>>>>
>>>>>> Only the visualization of real user name is still missing. I get only
>>>>>> the login name (short name) instead of the full name in the change
>>>>>> history and so on. Is it a default behaviour or misconfiguration?
>>>>>>
>>>>>> Nice greetings,
>>>>>> Harald
>>>>>>
>>>>>> - --
>>>>>>
>>>>>> Harald Krammer
>>>>>> Brucknerstrasse 33
>>>>>> A - 4020 Linz
>>>>>> AUSTRIA
>>>>>>
>>>>>> Mobil +43.(0) 664. 130 59 58
>>>>>> Mail: Harald.Krammer (at) hkr.at
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>>
>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>>>>>> =Kd7Y
>>>>>> -----END PGP SIGNATURE-----
>>>>>>
>>
>

- --

Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA

Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkrkGqEACgkQ9QlAsubHO9vsYACgriH34OZiGCZq6Ac2DayNJnd3
SKQAni/X1DtibeNEbZKtnzNAe+OHUwt2
=KwyM
-----END PGP SIGNATURE-----

Re: Visual LDAP user name

2009-10-24T08:12:27Z

JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer,
which means that it can obtain user profiles on a read-only basis from
LDAP, and obtain roles from LDAP groups. So if you use LDAP, your
users will be "provisioned" in JSPWiki automatically. This should
solve the user-experience problem you described.

The upcoming 3.0 LDAP features have been developed and tested with
Active Directory and OpenLDAP. It is configured via the GUI at
install-time.

With respect to permissions and group memberships: these are good
suggestions. We still have some work to do for the GUI for ACLs for
3.0. I agree that we should be validating user names when users create
the ACLs. Same for adding users to groups. These suggestions will be
incorporated into how the ACL GUIs work -- likely via AJAX in
real-time.

Andrew

On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@...> wrote:

> The group and permission system in the jspwiki is rather dynamic, and ldaps
> tends to be readonly except for a groups of administrators. There for there
> is still need for the user.xml and group.xml. But in my opinion the user.xml
> needs to be automatically updated when a new ldap user is logged in.
>
> Otherwise granting and managing jspwiki permissions i a nightmare, this also
> enhanced since there is no check on if a user exist - when adding users to
> wiki group or setting a page permission.
>
> I think the following should be changed.
>
> - First time a new user is logged in - the user should be added to the the
> user.xml and redirect to the profile page for setting additional information
> (email, full name and section edition etc)
>
> - Adding page permission should lookup if the group or the user exist.
>
> - Adding users to a wiki group should only be possible for existing users.
>
> /Thomas
>
>
> On Oct 24, 2009, at 10:57 , Jim Willeke wrote:
>
>> Why allow people to eliminate the user.xml?
>>
>> Why not allow the use of LDAP for the user profile?
>>
>> Allow mapping the LDAP attributes to the profile values?
>>
>> Enterprises have no desire to maintain another separate user store of
>> information. Many already have a central LDAP store.
>>
>> -jim
>> Jim Willeke
>>
>>
>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@...> wrote:
>>
>>> I would suggest a change, if a ldap user is logging the first time. the
>>> Wiki should create the user in the user.xml - it gives a lot of problem
>>> when
>>> adding a ldap user to a wiki group, since it possible that the user isn't
>>> created.
>>>
>>>
>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
>>>
>>> If a user creates a user profile after logging into the container, he or
>>>>
>>>> she will have an opportunity to specify a "full name." If a full name is
>>>> supplied, it will be used in page histories etc from that point forward.
>>>>
>>>> Andrew
>>>>
>>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...> wrote:
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>
>>>>> Hash: SHA256
>>>>>
>>>>> Hello,
>>>>> I run JSPWiki with Web Container Authentication via LDAP and it runs
>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
>>>>>
>>>>> Only the visualization of real user name is still missing. I get only
>>>>> the login name (short name) instead of the full name in the change
>>>>> history and so on. Is it a default behaviour or misconfiguration?
>>>>>
>>>>> Nice greetings,
>>>>> Harald
>>>>>
>>>>> - --
>>>>>
>>>>> Harald Krammer
>>>>> Brucknerstrasse 33
>>>>> A - 4020 Linz
>>>>> AUSTRIA
>>>>>
>>>>> Mobil +43.(0) 664. 130 59 58
>>>>> Mail: Harald.Krammer (at) hkr.at
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>
>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>>>>> =Kd7Y
>>>>> -----END PGP SIGNATURE-----
>>>>>
>>>>
>>>
>
>

Re: Visual LDAP user name

2009-10-24T04:25:22Z

The group and permission system in the jspwiki is rather dynamic, and
ldaps tends to be readonly except for a groups of administrators.
There for there is still need for the user.xml and group.xml. But in
my opinion the user.xml needs to be automatically updated when a new
ldap user is logged in.

Otherwise granting and managing jspwiki permissions i a nightmare,
this also enhanced since there is no check on if a user exist - when
adding users to wiki group or setting a page permission.

I think the following should be changed.

- First time a new user is logged in - the user should be added to the
the user.xml and redirect to the profile page for setting additional
information (email, full name and section edition etc)

- Adding page permission should lookup if the group or the user exist.

- Adding users to a wiki group should only be possible for existing
users.

/Thomas

On Oct 24, 2009, at 10:57 , Jim Willeke wrote:

> Why allow people to eliminate the user.xml?
>
> Why not allow the use of LDAP for the user profile?
>
> Allow mapping the LDAP attributes to the profile values?
>
> Enterprises have no desire to maintain another separate user store of
> information. Many already have a central LDAP store.
>
> -jim
> Jim Willeke
>
>
> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@...>
> wrote:
>
>> I would suggest a change, if a ldap user is logging the first
>> time. the
>> Wiki should create the user in the user.xml - it gives a lot of
>> problem when
>> adding a ldap user to a wiki group, since it possible that the user
>> isn't
>> created.
>>
>>
>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
>>
>> If a user creates a user profile after logging into the container,
>> he or
>>> she will have an opportunity to specify a "full name." If a full
>>> name is
>>> supplied, it will be used in page histories etc from that point
>>> forward.
>>>
>>> Andrew
>>>
>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...>
>>> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> Hello,
>>>> I run JSPWiki with Web Container Authentication via LDAP and it
>>>> runs
>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
>>>>
>>>> Only the visualization of real user name is still missing. I get
>>>> only
>>>> the login name (short name) instead of the full name in the change
>>>> history and so on. Is it a default behaviour or misconfiguration?
>>>>
>>>> Nice greetings,
>>>> Harald
>>>>
>>>> - --
>>>>
>>>> Harald Krammer
>>>> Brucknerstrasse 33
>>>> A - 4020 Linz
>>>> AUSTRIA
>>>>
>>>> Mobil +43.(0) 664. 130 59 58
>>>> Mail: Harald.Krammer (at) hkr.at
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>
>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>>>> =Kd7Y
>>>> -----END PGP SIGNATURE-----
>>>>
>>>
>>

Re: Visual LDAP user name

2009-10-24T01:57:13Z

Why allow people to eliminate the user.xml?

Why not allow the use of LDAP for the user profile?

Allow mapping the LDAP attributes to the profile values?

Enterprises have no desire to maintain another separate user store of
information. Many already have a central LDAP store.

-jim
Jim Willeke

On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@...> wrote:

> I would suggest a change, if a ldap user is logging the first time. the
> Wiki should create the user in the user.xml - it gives a lot of problem when
> adding a ldap user to a wiki group, since it possible that the user isn't
> created.
>
>
> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:
>
> If a user creates a user profile after logging into the container, he or
>> she will have an opportunity to specify a "full name." If a full name is
>> supplied, it will be used in page histories etc from that point forward.
>>
>> Andrew
>>
>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Hello,
>>> I run JSPWiki with Web Container Authentication via LDAP and it runs
>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
>>>
>>> Only the visualization of real user name is still missing. I get only
>>> the login name (short name) instead of the full name in the change
>>> history and so on. Is it a default behaviour or misconfiguration?
>>>
>>> Nice greetings,
>>> Harald
>>>
>>> - --
>>>
>>> Harald Krammer
>>> Brucknerstrasse 33
>>> A - 4020 Linz
>>> AUSTRIA
>>>
>>> Mobil +43.(0) 664. 130 59 58
>>> Mail: Harald.Krammer (at) hkr.at
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>
>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>>> =Kd7Y
>>> -----END PGP SIGNATURE-----
>>>
>>
>

Re: Visual LDAP user name

2009-10-23T11:09:25Z

I would suggest a change, if a ldap user is logging the first time.
the Wiki should create the user in the user.xml - it gives a lot of
problem when adding a ldap user to a wiki group, since it possible
that the user isn't created.

On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote:

> If a user creates a user profile after logging into the container,
> he or she will have an opportunity to specify a "full name." If a
> full name is supplied, it will be used in page histories etc from
> that point forward.
>
> Andrew
>
> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hello,
>> I run JSPWiki with Web Container Authentication via LDAP and it runs
>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
>>
>> Only the visualization of real user name is still missing. I get only
>> the login name (short name) instead of the full name in the change
>> history and so on. Is it a default behaviour or misconfiguration?
>>
>> Nice greetings,
>> Harald
>>
>> - --
>>
>> Harald Krammer
>> Brucknerstrasse 33
>> A - 4020 Linz
>> AUSTRIA
>>
>> Mobil +43.(0) 664. 130 59 58
>> Mail: Harald.Krammer (at) hkr.at
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
>> =Kd7Y
>> -----END PGP SIGNATURE-----

Re: Visual LDAP user name

2009-10-22T15:38:02Z

If a user creates a user profile after logging into the container, he
or she will have an opportunity to specify a "full name." If a full
name is supplied, it will be used in page histories etc from that
point forward.

Andrew

On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello,
> I run JSPWiki with Web Container Authentication via LDAP and it runs
> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).
>
> Only the visualization of real user name is still missing. I get only
> the login name (short name) instead of the full name in the change
> history and so on. Is it a default behaviour or misconfiguration?
>
> Nice greetings,
> Harald
>
> - --
>
> Harald Krammer
> Brucknerstrasse 33
> A - 4020 Linz
> AUSTRIA
>
> Mobil +43.(0) 664. 130 59 58
> Mail: Harald.Krammer (at) hkr.at
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
> =Kd7Y
> -----END PGP SIGNATURE-----

Visual LDAP user name

2009-10-22T13:34:56Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,
I run JSPWiki with Web Container Authentication via LDAP and it runs
fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6).

Only the visualization of real user name is still missing. I get only
the login name (short name) instead of the full name in the change
history and so on. Is it a default behaviour or misconfiguration?

Nice greetings,
Harald

- --

Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA

Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ
w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0
=Kd7Y
-----END PGP SIGNATURE-----

Re: Links with [ or ] symbols

2009-10-20T10:58:13Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Janne,
no, I didn't know that. This illegal characters are included on a
external URL.

Thanks it works.
Greetings,
Harald

Janne Jalkanen schrieb:

>
> You gotta realize that "[" and "]" are illegal characters in URLs. So
> you need to replace them with their percent-encoding versions (which
> your browser might do automatically), just like what you would do with
> regular HTML.
>
> %5B = [
> %5D = ]
>
> /Janne
>
> On Oct 19, 2009, at 22:19 , Harald Krammer wrote:
>
> Hello,
> what's is the right method to add links with '['or ']' symbols into
> JSPWiki?
>
> e.g. http://foo.bar/?balbal[problemcmd]blabla[moreproblems]
>
> Solution like [my link;
> http://foo.bar/?balbal[problemcmd]blabla[moreproblems]] doesn't work.
>
> Any helps are welcome
> Harald

- --

Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA

Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkrd+isACgkQ9QlAsubHO9u3LgCfQ2PgKzwll3yxcqHBuuMSjTHJ
rqYAnjHBIV6BUgwt5k7868mSQgtJGZku
=sEW0
-----END PGP SIGNATURE-----

Re: Links with [ or ] symbols

2009-10-19T13:12:23Z

You gotta realize that "[" and "]" are illegal characters in URLs. So
you need to replace them with their percent-encoding versions (which
your browser might do automatically), just like what you would do with
regular HTML.

%5B = [
%5D = ]

/Janne

On Oct 19, 2009, at 22:19 , Harald Krammer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello,
> what's is the right method to add links with '['or ']' symbols into
> JSPWiki?
>
> e.g. http://foo.bar/?balbal[problemcmd]blabla[moreproblems]
>
> Solution like [my link;
> http://foo.bar/?balbal[problemcmd]blabla[moreproblems]] doesn't work.
>
> Any helps are welcome
> Harald
> - --
>
> Harald Krammer
> Brucknerstrasse 33
> A - 4020 Linz
> AUSTRIA
>
> Mobil +43.(0) 664. 130 59 58
> Mail: Harald.Krammer (at) hkr.at
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREIAAYFAkrcu7QACgkQ9QlAsubHO9u1jwCcDoQ+x0wty/MoTQE9f+W3chJM
> BXsAn08HdYsENP+kgTFA1AjJNgouVl5c
> =5Juu
> -----END PGP SIGNATURE-----

Links with [ or ] symbols

2009-10-19T12:19:23Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,
what's is the right method to add links with '['or ']' symbols into JSPWiki?

e.g. http://foo.bar/?balbal[problemcmd]blabla[moreproblems]

Solution like [my link;
http://foo.bar/?balbal[problemcmd]blabla[moreproblems]] doesn't work.

Any helps are welcome
Harald
- --

Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA

Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkrcu7QACgkQ9QlAsubHO9u1jwCcDoQ+x0wty/MoTQE9f+W3chJM
BXsAn08HdYsENP+kgTFA1AjJNgouVl5c
=5Juu
-----END PGP SIGNATURE-----

Re: Web Container Authentication Via LDAP

2009-10-15T01:52:08Z

Do you have the connector using the correct parameters for the keystore?
The entries should/could be something like:


<Connector port="8443"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false"
disableUploadTimeout="true"
debug="99"
acceptCount="100"
scheme="https"
secure="true"
keystoreFile="<keystore_filename>"
keystorePass="changeit"
truststoreFile="<trustcacerts-filename>"
truststorePass="changeit"
clientAuth="false"
sslProtocol="TLS" />

-jim
Jim Willeke

On Wed, Oct 14, 2009 at 5:19 PM, Andrew Jaquith
<andrew.r.jaquith@...>wrote:

> I don't know what to tell you, exactly. You can try troubleshooting
> Tomcat's SSL connection by adding this to your CATALINA_OPTS
> environment variable:
>
> -Djavax.net.debug=all
>
> You'll see a LOT of diagnostic information as a result. You can also
> fine-tune SSL debugging so you just see trust-store issues, for
> example. See the docs here:
>
> http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/ReadDebug.html
>
> If that doesn't work, then you likely have deeper LDAP connectivity
> problems than just SSL certificates. You should figure out what those
> are before proceeding further with the Java certificate store
> troubleshooting.
>
> What you should do in that case is use a different LDAP client (for
> example, the Unix 'ldapsearch' command line tool) to verify that you
> can connect to LDAP outside of Tomcat. Once you know the exact base
> DN, search string, SSL setting, etc to use, you'll know how to
> configure it in Tomcat.
>
> I can't give you much more guidance than that. Please don't ask for
> detailed HOWTOs on either of these points -- Google is your friend,
> and will be friendlier to you than I am willing to be at this point.
> Frankly, this is not really a JSPWiki issue -- it's a Tomcat issue.
> You might also want to try the tomcat-user mailing list.
>
> Andrew
>
> On Mon, Oct 12, 2009 at 4:54 AM, anilkumarkatta
> <anilkumarkatta@...> wrote:
> >
> > yes, i did.
> >
> > I have multiple installation on my machine with different versions of the
> > JVM. I installed the new certicates using InstallCert.java program as
> > suggested and crosschecked those intalled cert in the cercert file using
> > keytool list command.
> >
> > still the same issue. does the application war require any .jks files or
> > .cer file. ?
> >
> > Please advice
> >
> >
> > Jim Willeke wrote:
> >>
> >> Did you look in the jre?
> >>
> >> If you are using a JDK then the file would be:
> >> \jdk1.6.0_14\jre\lib\security\cacerts
> >>
> >>
> >> -jim
> >> Jim Willeke
> >>
> >>
> >> On Fri, Oct 9, 2009 at 5:51 AM, anilkumarkatta
> >> <anilkumarkatta@...>wrote:
> >>
> >>>
> >>>
> >>> Hi All
> >>>
> >>> Thanks for you replies.
> >>>
> >>> I have tried installing the ssl for the url. but same issue.
> >>>
> >>> I took some time to check how the existing url's ssl is done in
> >>> keystore..
> >>> but find nothing in java_home/lib/security.
> >>>
> >>> how this can be no ssl certifcates in keystore?
> >>>
> >>> if they keystore is exists in app level where does it saved in
> >>> application
> >>>
> >>> Thanks again for the replies.
> >>>
> >>> -Anil
> >>>
> >>>
> >>> Andrew Jaquith-4 wrote:
> >>> >
> >>> > You are pretty new to this whole Java thing aren't you?
> >>> >
> >>> > It appears that 1) your LDAP server requires SSL (a good thing!) and
> >>> > that 2) your LDAP's SSL certificate is self-signed and therefore not
> >>> > trusted.
> >>> >
> >>> > Java keeps an internal list of SSL certs it trusts. Your self-signed
> >>> > CA is not one of them. You need to add the SSL certificate CA (that
> >>> > is, the self-signed root) to your local JSSE trusted certificate
> >>> > store. This is at $JAVA_HOME/lib/security/cacerts.
> >>> >
> >>> > The Java command line tool "keytool" can do this. You can also use my
> >>> > SSLHelper class, part of my freshcookies-security.jar that ships with
> >>> > JSPWiki. Indeed, I wrote it for just this situation. See the docs at
> >>> > freshcookies.org
> >>> > for details.
> >>> >
> >>> > With either aproach, you will need appprpriate admin rights to modify
> >>> > the truststore.
> >>> >
> >>> > Andrew
> >>> >
> >>> > On Oct 6, 2009, at 8:29, anilkumarkatta <anilkumarkatta@...>
> >>> > wrote:
> >>> >
> >>> >>
> >>> >>
> >>> >> ....contd.
> >>> >> Caused by: javax.net.ssl.SSLHandshakeException:
> >>> >> sun.security.validator.ValidatorException: PKIX path building
> failed:
> >>> >> sun.security.provider.certpath.SunCertPathBuilderException: unable
> >>> >> to find
> >>> >> valid certification path to requested target
> >>> >>
> >>> >>
> >>> >> anilkumarkatta wrote:
> >>> >>>
> >>> >>> Hi All
> >>> >>>
> >>> >>> I have tried to authenticate via LDAP server with all the
> >>> >>> configuration
> >>> >>> procedure explained in the URL
> >>> >>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP
> >>> >>> with a user provided LDAP settings, I got firewall team to get the
> >>> >>> secure
> >>> >>> port open from where application is talking to the LDAP.
> >>> >>>
> >>> >>> i am getting this exception while start of the application
> >>> >>>
> >>> >>>
> >>> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
> >>> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
> >>> >>> membership established, start level:4
> >>> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
> >>> >>> org.apache.catalina.tribes.membership.McastService - Sleeping for
> >>> >>> 1000
> >>> >>> milliseconds to establish cluster membership, start level:8
> >>> >>> 2009-10-06 22:14:05,581 [Thread-2] INFO
> >>> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
> >>> >>> membership established, start level:8
> >>> >>> 2009-10-06 22:14:06,144 [Thread-2] WARN
> >>> >>> org.apache.catalina.core.ContainerBase.[Catalina] - Exception
> >>> >>> performing
> >>> >>> authentication
> >>> >>> javax.naming.CommunicationException: simple bind failed:
> >>> >>> ARTE001.MYDOMAIN.AK.com:636 [Root exception is
> >>> >>> javax.net.ssl.SSLHandshakeException:
> >>> >>> sun.security.validator.ValidatorException: PKIX path building
> failed:
> >>> >>> sun.security.provider.certpath.SunCertPathBuilderException: unable
> >>> >>> to find
> >>> >>> valid certification path to requested target]
> >>> >>> at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source)
> >>> >>> at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
> >>> >>> at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
> >>> >>>
> >>> >>>
> >>> >>> where as when I place other deatails of the LDAP its working fine.
> >>> >>> does this required any cerification files like .jks files.. if so
> >>> >>> where
> >>> >>> shall I place them?
> >>> >>>
> >>> >>> your replies are most welcome
> >>> >>>
> >>> >>> Regards,
> >>> >>> -Anil Katta
> >>> >>>
> >>> >>
> >>> >> --
> >>> >> View this message in context:
> >>> >>
> >>>
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25767801.html
> >>> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>> >>
> >>> >
> >>> >
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25818421.html
> >>> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>>
> >>>
> >>
> >>
> >
> > --
> > View this message in context:
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25852406.html
> > Sent from the JspWiki - User mailing list archive at Nabble.com.
> >
> >
>

Re: Web Container Authentication Via LDAP

2009-10-14T14:19:34Z

I don't know what to tell you, exactly. You can try troubleshooting
Tomcat's SSL connection by adding this to your CATALINA_OPTS
environment variable:

-Djavax.net.debug=all

You'll see a LOT of diagnostic information as a result. You can also
fine-tune SSL debugging so you just see trust-store issues, for
example. See the docs here:

http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/ReadDebug.html

If that doesn't work, then you likely have deeper LDAP connectivity
problems than just SSL certificates. You should figure out what those
are before proceeding further with the Java certificate store
troubleshooting.

What you should do in that case is use a different LDAP client (for
example, the Unix 'ldapsearch' command line tool) to verify that you
can connect to LDAP outside of Tomcat. Once you know the exact base
DN, search string, SSL setting, etc to use, you'll know how to
configure it in Tomcat.

I can't give you much more guidance than that. Please don't ask for
detailed HOWTOs on either of these points -- Google is your friend,
and will be friendlier to you than I am willing to be at this point.
Frankly, this is not really a JSPWiki issue -- it's a Tomcat issue.
You might also want to try the tomcat-user mailing list.

Andrew

On Mon, Oct 12, 2009 at 4:54 AM, anilkumarkatta
<anilkumarkatta@...> wrote:

>
> yes, i did.
>
> I have multiple installation on my machine with different versions of the
> JVM. I installed the new certicates using InstallCert.java program as
> suggested and crosschecked those intalled cert in the cercert file using
> keytool list command.
>
> still the same issue. does the application war require any .jks files or
> .cer file. ?
>
> Please advice
>
>
> Jim Willeke wrote:
>>
>> Did you look in the jre?
>>
>> If you are using a JDK then the file would be:
>> \jdk1.6.0_14\jre\lib\security\cacerts
>>
>>
>> -jim
>> Jim Willeke
>>
>>
>> On Fri, Oct 9, 2009 at 5:51 AM, anilkumarkatta
>> <anilkumarkatta@...>wrote:
>>
>>>
>>>
>>> Hi All
>>>
>>> Thanks for you replies.
>>>
>>> I have tried installing the ssl for the url. but same issue.
>>>
>>> I took some time to check how the existing url's ssl is done in
>>> keystore..
>>> but find nothing in java_home/lib/security.
>>>
>>> how this can be no ssl certifcates in keystore?
>>>
>>> if they keystore is exists in app level where does it saved in
>>> application
>>>
>>> Thanks again for the replies.
>>>
>>> -Anil
>>>
>>>
>>> Andrew Jaquith-4 wrote:
>>> >
>>> > You are pretty new to this whole Java thing aren't you?
>>> >
>>> > It appears that 1) your LDAP server requires SSL (a good thing!) and
>>> > that 2) your LDAP's SSL certificate is self-signed and therefore not
>>> > trusted.
>>> >
>>> > Java keeps an internal list of SSL certs it trusts. Your self-signed
>>> > CA is not one of them. You need to add the SSL certificate CA (that
>>> > is, the self-signed root) to your local JSSE trusted certificate
>>> > store. This is at $JAVA_HOME/lib/security/cacerts.
>>> >
>>> > The Java command line tool "keytool" can do this. You can also use my
>>> > SSLHelper class, part of my freshcookies-security.jar that ships with
>>> > JSPWiki. Indeed, I wrote it for just this situation. See the docs at
>>> > freshcookies.org
>>> > for details.
>>> >
>>> > With either aproach, you will need appprpriate admin rights to modify
>>> > the truststore.
>>> >
>>> > Andrew
>>> >
>>> > On Oct 6, 2009, at 8:29, anilkumarkatta <anilkumarkatta@...>
>>> > wrote:
>>> >
>>> >>
>>> >>
>>> >> ....contd.
>>> >> Caused by: javax.net.ssl.SSLHandshakeException:
>>> >> sun.security.validator.ValidatorException: PKIX path building failed:
>>> >> sun.security.provider.certpath.SunCertPathBuilderException: unable
>>> >> to find
>>> >> valid certification path to requested target
>>> >>
>>> >>
>>> >> anilkumarkatta wrote:
>>> >>>
>>> >>> Hi All
>>> >>>
>>> >>> I have tried to authenticate via LDAP server with all the
>>> >>> configuration
>>> >>> procedure explained in the URL
>>> >>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP
>>> >>> with a user provided LDAP settings, I got firewall team to get the
>>> >>> secure
>>> >>> port open from where application is talking to the LDAP.
>>> >>>
>>> >>> i am getting this exception while start of the application
>>> >>>
>>> >>>
>>> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
>>> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
>>> >>> membership established, start level:4
>>> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
>>> >>> org.apache.catalina.tribes.membership.McastService - Sleeping for
>>> >>> 1000
>>> >>> milliseconds to establish cluster membership, start level:8
>>> >>> 2009-10-06 22:14:05,581 [Thread-2] INFO
>>> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
>>> >>> membership established, start level:8
>>> >>> 2009-10-06 22:14:06,144 [Thread-2] WARN
>>> >>> org.apache.catalina.core.ContainerBase.[Catalina] - Exception
>>> >>> performing
>>> >>> authentication
>>> >>> javax.naming.CommunicationException: simple bind failed:
>>> >>> ARTE001.MYDOMAIN.AK.com:636 [Root exception is
>>> >>> javax.net.ssl.SSLHandshakeException:
>>> >>> sun.security.validator.ValidatorException: PKIX path building failed:
>>> >>> sun.security.provider.certpath.SunCertPathBuilderException: unable
>>> >>> to find
>>> >>> valid certification path to requested target]
>>> >>> at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source)
>>> >>> at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
>>> >>> at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
>>> >>>
>>> >>>
>>> >>> where as when I place other deatails of the LDAP its working fine.
>>> >>> does this required any cerification files like .jks files.. if so
>>> >>> where
>>> >>> shall I place them?
>>> >>>
>>> >>> your replies are most welcome
>>> >>>
>>> >>> Regards,
>>> >>> -Anil Katta
>>> >>>
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25767801.html
>>> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25818421.html
>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25852406.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.
>
>

Re: interesting user logon problem

2009-10-12T11:35:56Z

This indeed looks very much like you are accessing your JSPWiki with a
"wrong URL", a URL that is different from the baseURL configured in
jspwiki.properties.(like Madu also suggested)

Once you login, you are redirected to the baseURL and have to log in again.
It has nothing todo with RACF.

regards,
Harry

2009/10/12 Ben Thompson <Ben.Thompson@...>

> I have an interesting issue, with one user who has to logon twice to be
> authenticated to JSPWiki. All the other 25 users, including myself do
> not have this problem. We are running JSPWiki 2.8.2 with RACF for our
> authentication, but it turns out that the user had the same problem
> under JSPWiki 2.8.1 using JSPWiki's authentication. The users has to
> logon twice to be authenticated to JSPWiki under both Explorer and
> Firefox. We have removed all cookies from both Explorer and Firefox,
> this has not made a difference.
>
>
>
> The step to logon are:
>
> * When at the JSPWiki home page, G'day (anonymous guest) appears
> next to login.
>
>
>
> * click Login and Login page displays.
>
>
>
> * fill in RACF username & Password.
>
>
>
> * JSPWiki home page is displayed with G'day (anonymous guest)
> appearing against the login again, user still does not have access.
>
>
>
> * Repeat the process by clicking on the login and login page
> displays.
>
>
>
> * Fill in RACF username & Password , JSPWiki home page is
> displayed with G'day, XXX(authenticated). And at this stage the user
> can access the info in JSPWiki.
>
>
>
> Any ideas on what's going on here
>
>
>
> Thanks
>
>
>
> Benjamin Thompson
> Systems Programmer
> Data Centre Services
> Northern Territory Government
>
> twitter:benthompsonau
> ph (08) 89997693
>
>
>
>

Re: Web Container Authentication Via LDAP

2009-10-12T01:54:33Z

yes, i did.

I have multiple installation on my machine with different versions of the JVM. I installed the new certicates using InstallCert.java program as suggested and crosschecked those intalled cert in the cercert file using keytool list command.

still the same issue. does the application war require any .jks files or .cer file. ?

Please advice

Jim Willeke wrote:

Did you look in the jre?

If you are using a JDK then the file would be:
\jdk1.6.0_14\jre\lib\security\cacerts

-jim
Jim Willeke

On Fri, Oct 9, 2009 at 5:51 AM, anilkumarkatta <anilkumarkatta@gmail.com>wrote:

>
>
> Hi All
>
> Thanks for you replies.
>
> I have tried installing the ssl for the url. but same issue.
>
> I took some time to check how the existing url's ssl is done in keystore..
> but find nothing in java_home/lib/security.
>
> how this can be no ssl certifcates in keystore?
>
> if they keystore is exists in app level where does it saved in application
>
> Thanks again for the replies.
>
> -Anil
>
>
> Andrew Jaquith-4 wrote:
> >
> > You are pretty new to this whole Java thing aren't you?
> >
> > It appears that 1) your LDAP server requires SSL (a good thing!) and
> > that 2) your LDAP's SSL certificate is self-signed and therefore not
> > trusted.
> >
> > Java keeps an internal list of SSL certs it trusts. Your self-signed
> > CA is not one of them. You need to add the SSL certificate CA (that
> > is, the self-signed root) to your local JSSE trusted certificate
> > store. This is at $JAVA_HOME/lib/security/cacerts.
> >
> > The Java command line tool "keytool" can do this. You can also use my
> > SSLHelper class, part of my freshcookies-security.jar that ships with
> > JSPWiki. Indeed, I wrote it for just this situation. See the docs at
> > freshcookies.org
> > for details.
> >
> > With either aproach, you will need appprpriate admin rights to modify
> > the truststore.
> >
> > Andrew
> >
> > On Oct 6, 2009, at 8:29, anilkumarkatta <anilkumarkatta@gmail.com>
> > wrote:
> >
> >>
> >>
> >> ....contd.
> >> Caused by: javax.net.ssl.SSLHandshakeException:
> >> sun.security.validator.ValidatorException: PKIX path building failed:
> >> sun.security.provider.certpath.SunCertPathBuilderException: unable
> >> to find
> >> valid certification path to requested target
> >>
> >>
> >> anilkumarkatta wrote:
> >>>
> >>> Hi All
> >>>
> >>> I have tried to authenticate via LDAP server with all the
> >>> configuration
> >>> procedure explained in the URL
> >>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP
> >>> with a user provided LDAP settings, I got firewall team to get the
> >>> secure
> >>> port open from where application is talking to the LDAP.
> >>>
> >>> i am getting this exception while start of the application
> >>>
> >>>
> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
> >>> membership established, start level:4
> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
> >>> org.apache.catalina.tribes.membership.McastService - Sleeping for
> >>> 1000
> >>> milliseconds to establish cluster membership, start level:8
> >>> 2009-10-06 22:14:05,581 [Thread-2] INFO
> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
> >>> membership established, start level:8
> >>> 2009-10-06 22:14:06,144 [Thread-2] WARN
> >>> org.apache.catalina.core.ContainerBase.[Catalina] - Exception
> >>> performing
> >>> authentication
> >>> javax.naming.CommunicationException: simple bind failed:
> >>> ARTE001.MYDOMAIN.AK.com:636 [Root exception is
> >>> javax.net.ssl.SSLHandshakeException:
> >>> sun.security.validator.ValidatorException: PKIX path building failed:
> >>> sun.security.provider.certpath.SunCertPathBuilderException: unable
> >>> to find
> >>> valid certification path to requested target]
> >>> at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source)
> >>> at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
> >>> at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
> >>>
> >>>
> >>> where as when I place other deatails of the LDAP its working fine.
> >>> does this required any cerification files like .jks files.. if so
> >>> where
> >>> shall I place them?
> >>>
> >>> your replies are most welcome
> >>>
> >>> Regards,
> >>> -Anil Katta
> >>>
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25767801.html
> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25818421.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.
>
>

Re: interesting user logon problem

2009-10-11T20:52:31Z

Given that JSPWiki doesn't ship out-of-the box with RACF support,
would you mind describing your configuration in more detail? In
particular, how is your authentication configured?

Andrew

On Sun, Oct 11, 2009 at 9:38 PM, Ben Thompson <Ben.Thompson@...> wrote:

RE: interesting user logon problem

2009-10-11T20:38:01Z

This happens to me when first time user logged in from DOMAIN.COM and next time WWW.DOMAIN.COM.
If the user logged in from WWW.DOMAIN.COM from the first time itself, user is not re-prompted to login.

Did not have time to investigate in detail yet. But I suspect its coming from Cookie/JAAS combination??

/Madu

-----Original Message-----
From: Ben Thompson [mailto:Ben.Thompson@...]
Sent: Monday, 12 October 2009 12:39 PM
To: jspwiki-user@...
Subject: interesting user logon problem

I have an interesting issue, with one user who has to logon twice to be
authenticated to JSPWiki. All the other 25 users, including myself do
not have this problem. We are running JSPWiki 2.8.2 with RACF for our
authentication, but it turns out that the user had the same problem
under JSPWiki 2.8.1 using JSPWiki's authentication. The users has to
logon twice to be authenticated to JSPWiki under both Explorer and
Firefox. We have removed all cookies from both Explorer and Firefox,
this has not made a difference.

The step to logon are:

* When at the JSPWiki home page, G'day (anonymous guest) appears
next to login.

* click Login and Login page displays.

* fill in RACF username & Password.

* JSPWiki home page is displayed with G'day (anonymous guest)
appearing against the login again, user still does not have access.

* Repeat the process by clicking on the login and login page
displays.

* Fill in RACF username & Password , JSPWiki home page is
displayed with G'day, XXX(authenticated). And at this stage the user
can access the info in JSPWiki.

Any ideas on what's going on here

Thanks

Benjamin Thompson
Systems Programmer
Data Centre Services
Northern Territory Government

twitter:benthompsonau
ph (08) 89997693

interesting user logon problem

2009-10-11T18:38:56Z

I have an interesting issue, with one user who has to logon twice to be
authenticated to JSPWiki. All the other 25 users, including myself do
not have this problem. We are running JSPWiki 2.8.2 with RACF for our
authentication, but it turns out that the user had the same problem
under JSPWiki 2.8.1 using JSPWiki's authentication. The users has to
logon twice to be authenticated to JSPWiki under both Explorer and
Firefox. We have removed all cookies from both Explorer and Firefox,
this has not made a difference.

The step to logon are:

* When at the JSPWiki home page, G'day (anonymous guest) appears
next to login.

* click Login and Login page displays.

* fill in RACF username & Password.

* JSPWiki home page is displayed with G'day (anonymous guest)
appearing against the login again, user still does not have access.

* Repeat the process by clicking on the login and login page
displays.

* Fill in RACF username & Password , JSPWiki home page is
displayed with G'day, XXX(authenticated). And at this stage the user
can access the info in JSPWiki.

Any ideas on what's going on here

Thanks

Benjamin Thompson
Systems Programmer
Data Centre Services
Northern Territory Government

twitter:benthompsonau
ph (08) 89997693

Re: Web Container Authentication Via LDAP

2009-10-09T03:42:30Z

Did you look in the jre?

If you are using a JDK then the file would be:
\jdk1.6.0_14\jre\lib\security\cacerts

-jim
Jim Willeke

On Fri, Oct 9, 2009 at 5:51 AM, anilkumarkatta <anilkumarkatta@...>wrote:

>
>
> Hi All
>
> Thanks for you replies.
>
> I have tried installing the ssl for the url. but same issue.
>
> I took some time to check how the existing url's ssl is done in keystore..
> but find nothing in java_home/lib/security.
>
> how this can be no ssl certifcates in keystore?
>
> if they keystore is exists in app level where does it saved in application
>
> Thanks again for the replies.
>
> -Anil
>
>
> Andrew Jaquith-4 wrote:
> >
> > You are pretty new to this whole Java thing aren't you?
> >
> > It appears that 1) your LDAP server requires SSL (a good thing!) and
> > that 2) your LDAP's SSL certificate is self-signed and therefore not
> > trusted.
> >
> > Java keeps an internal list of SSL certs it trusts. Your self-signed
> > CA is not one of them. You need to add the SSL certificate CA (that
> > is, the self-signed root) to your local JSSE trusted certificate
> > store. This is at $JAVA_HOME/lib/security/cacerts.
> >
> > The Java command line tool "keytool" can do this. You can also use my
> > SSLHelper class, part of my freshcookies-security.jar that ships with
> > JSPWiki. Indeed, I wrote it for just this situation. See the docs at
> > freshcookies.org
> > for details.
> >
> > With either aproach, you will need appprpriate admin rights to modify
> > the truststore.
> >
> > Andrew
> >
> > On Oct 6, 2009, at 8:29, anilkumarkatta <anilkumarkatta@...>
> > wrote:
> >
> >>
> >>
> >> ....contd.
> >> Caused by: javax.net.ssl.SSLHandshakeException:
> >> sun.security.validator.ValidatorException: PKIX path building failed:
> >> sun.security.provider.certpath.SunCertPathBuilderException: unable
> >> to find
> >> valid certification path to requested target
> >>
> >>
> >> anilkumarkatta wrote:
> >>>
> >>> Hi All
> >>>
> >>> I have tried to authenticate via LDAP server with all the
> >>> configuration
> >>> procedure explained in the URL
> >>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP
> >>> with a user provided LDAP settings, I got firewall team to get the
> >>> secure
> >>> port open from where application is talking to the LDAP.
> >>>
> >>> i am getting this exception while start of the application
> >>>
> >>>
> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
> >>> membership established, start level:4
> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
> >>> org.apache.catalina.tribes.membership.McastService - Sleeping for
> >>> 1000
> >>> milliseconds to establish cluster membership, start level:8
> >>> 2009-10-06 22:14:05,581 [Thread-2] INFO
> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
> >>> membership established, start level:8
> >>> 2009-10-06 22:14:06,144 [Thread-2] WARN
> >>> org.apache.catalina.core.ContainerBase.[Catalina] - Exception
> >>> performing
> >>> authentication
> >>> javax.naming.CommunicationException: simple bind failed:
> >>> ARTE001.MYDOMAIN.AK.com:636 [Root exception is
> >>> javax.net.ssl.SSLHandshakeException:
> >>> sun.security.validator.ValidatorException: PKIX path building failed:
> >>> sun.security.provider.certpath.SunCertPathBuilderException: unable
> >>> to find
> >>> valid certification path to requested target]
> >>> at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source)
> >>> at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
> >>> at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
> >>>
> >>>
> >>> where as when I place other deatails of the LDAP its working fine.
> >>> does this required any cerification files like .jks files.. if so
> >>> where
> >>> shall I place them?
> >>>
> >>> your replies are most welcome
> >>>
> >>> Regards,
> >>> -Anil Katta
> >>>
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25767801.html
> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25818421.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.
>
>

Re: Web Container Authentication Via LDAP

2009-10-09T02:51:34Z

Hi All

Thanks for you replies.

I have tried installing the ssl for the url. but same issue.

I took some time to check how the existing url's ssl is done in keystore.. but find nothing in java_home/lib/security.

how this can be no ssl certifcates in keystore?

if they keystore is exists in app level where does it saved in application

Thanks again for the replies.

-Anil

Andrew Jaquith-4 wrote:

You are pretty new to this whole Java thing aren't you?

It appears that 1) your LDAP server requires SSL (a good thing!) and
that 2) your LDAP's SSL certificate is self-signed and therefore not
trusted.

Java keeps an internal list of SSL certs it trusts. Your self-signed
CA is not one of them. You need to add the SSL certificate CA (that
is, the self-signed root) to your local JSSE trusted certificate
store. This is at $JAVA_HOME/lib/security/cacerts.

The Java command line tool "keytool" can do this. You can also use my
SSLHelper class, part of my freshcookies-security.jar that ships with
JSPWiki. Indeed, I wrote it for just this situation. See the docs at freshcookies.org
for details.

With either aproach, you will need appprpriate admin rights to modify
the truststore.

Andrew

On Oct 6, 2009, at 8:29, anilkumarkatta <anilkumarkatta@gmail.com>
wrote:

>
>
> ....contd.
> Caused by: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable
> to find
> valid certification path to requested target
>
>
> anilkumarkatta wrote:
>>
>> Hi All
>>
>> I have tried to authenticate via LDAP server with all the
>> configuration
>> procedure explained in the URL
>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP
>> with a user provided LDAP settings, I got firewall team to get the
>> secure
>> port open from where application is talking to the LDAP.
>>
>> i am getting this exception while start of the application
>>
>>
>> 2009-10-06 22:14:04,581 [Thread-2] INFO
>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
>> membership established, start level:4
>> 2009-10-06 22:14:04,581 [Thread-2] INFO
>> org.apache.catalina.tribes.membership.McastService - Sleeping for
>> 1000
>> milliseconds to establish cluster membership, start level:8
>> 2009-10-06 22:14:05,581 [Thread-2] INFO
>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
>> membership established, start level:8
>> 2009-10-06 22:14:06,144 [Thread-2] WARN
>> org.apache.catalina.core.ContainerBase.[Catalina] - Exception
>> performing
>> authentication
>> javax.naming.CommunicationException: simple bind failed:
>> ARTE001.MYDOMAIN.AK.com:636 [Root exception is
>> javax.net.ssl.SSLHandshakeException:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable
>> to find
>> valid certification path to requested target]
>> at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source)
>> at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
>> at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
>>
>>
>> where as when I place other deatails of the LDAP its working fine.
>> does this required any cerification files like .jks files.. if so
>> where
>> shall I place them?
>>
>> your replies are most welcome
>>
>> Regards,
>> -Anil Katta
>>
>
> --
> View this message in context: http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25767801.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.
>

Re: RESOLVED: Upgrade from v2.0.52 to v2.8.1 has broken attachments

2009-10-09T01:36:31Z

Hi All

I'm sorry with my short message.

I tried with the patch suggest by Christoph. but di'nt any resolution to my issue. still the same error that i'm getting and the image is not download.

logs are showing the same as I posted earlier

com.ecyrd.jspwiki.providers.CachingAttachmentProvider exceptions

Please do let me know if you require any additional information

Thanks & Regards,
-Anil Katta

Christoph Trattner wrote:

Can you provide information about your log output here?

best,
christoph

anilkumarkatta schrieb:
> No luck. :-(
>
>
> Harry Metske wrote:
>
>> Anil,
>> can you verify/test this proposed patch ?
>> Then, please open up a JIRA issue at
>> https://issues.apache.org/jira/browse/JSPWIKI and we can take the patch
>> in.
>>
>> thanks Christoph,
>>
>> Harry
>>
>> 2009/10/7 <ctrattner@iicm.edu>
>>
>>
>>> Hi,
>>>
>>> had the same exception because of corrupted or missing prop. files.
>>> Maybe you go to BasicAttachmentProvider Line 513 und replace
>>>
>>> throw new ProviderException("Attachment disappeared while reading
>>> information:"+
>>> " if you did not
>>> touch the repository, there is a serious bug somewhere. "+
>>> "Attachment =
>>> "+attachments[i]+
>>> ", decoded =
>>> "+attachmentName );
>>>
>>> with
>>>
>>> a simple "continue" statement.
>>>
>>> This should fix the issue with messed up repos.
>>>
>>> Best Regards,
>>> Christoph
>>>
>>> ---
>>>
>>> Check out the Austria version of JSPWiki 3.0
>>> www.austria-lexikon.at(beeing opened to the public on 9th of October)
>>>
>>>
>>> Zitat von Harry Metske <harry.metske@gmail.com>:
>>>
>>>
>>> I'm out of options, I have no idea what is wrong here.
>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2009/10/6 anilkumarkatta <anilkumarkatta@gmail.com>
>>>>
>>>>
>>>>
>>>>> Thank you very much for the email.
>>>>>
>>>>> These are the logs from my server
>>>>>
>>>>> 2009-10-06 20:08:40,566 [Thread-2] INFO com.ecyrd.jspwiki.WikiEngine -
>>>>> JSPWiki working directory is 'E:\JSPWiki\work'
>>>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
>>>>> com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are read
>>>>> from
>>>>> 'E:\JSPWiki\data'
>>>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
>>>>> com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
>>>>> E:\JSPWiki\data\OLD for storing old versions of pages
>>>>>
>>>>> I checked with the all the user permissions all looks good.
>>>>>
>>>>> all the attachement goes into the E:\jspwiki\data
>>>>> for that particular page it stores like this
>>>>> <pagename>-att\<filename>.<ext>-dir
>>>>> eg: Main-att\anil.java-dir
>>>>> in which files stored as
>>>>> <versionNo>.<ext> and attachment.properties
>>>>> eg. 1.java or 2.java and etc.
>>>>>
>>>>> Please resond with your suggestion what I do further on this.
>>>>>
>>>>> Thanks & Regards,
>>>>> -Anil Katta
>>>>>
>>>>>
>>>>> Harry Metske wrote:
>>>>>
>>>>>> I would think there is something wrong with your pageDir and/or
>>>>>> attachmentDir.Verify your jspwiki.properties for these two props:
>>>>>>
>>>>>> jspwiki.fileSystemProvider.pageDir
>>>>>> jspwiki.basicAttachmentProvider.storageDir
>>>>>>
>>>>>> Set the loglevel to at least info, and verify if you see any errors
>>>>>>
>>>>> during
>>>>>
>>>>>> startup of the wiki .
>>>>>> You should see messages like these :
>>>>>> 2009-09-24 19:26:53,813 [main] INFO
>>>>>> com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are
>>>>>>
>>>>> read
>>>>>
>>>>>> from
>>>>>> '/var/jspwiki/pages'
>>>>>> 2009-09-24 19:26:53,813 [main] INFO
>>>>>> com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
>>>>>> /var/jspwiki/pages/OLD for storing old versions of pages
>>>>>>
>>>>>> Also verify that the user that your wiki runs with, has read/write
>>>>>>
>>>>> access
>>>>>
>>>>>> to
>>>>>> the above directories.
>>>>>> And since it looks like you are running on Windows, check the double
>>>>>> backslashes.
>>>>>>
>>>>>> If you attach a file to a page (with different suffixes) where are
>>>>>>
>>>>> they
>>>>>
>>>>>> stored ?
>>>>>>
>>>>>> It really is an odd problem, I have never seen it before, so it must
>>>>>>
>>>>> be
>>>>> an
>>>>>
>>>>>> environmental or configuration error somewhere.
>>>>>>
>>>>>> regards,
>>>>>> Harry
>>>>>>
>>>>>> 2009/10/5 anilkumarkatta <anilkumarkatta@gmail.com>
>>>>>>
>>>>>>
>>>>>>> Thank you all for all replies..
>>>>>>>
>>>>>>> Yes 'm running apache web server before tomcat server.
>>>>>>> i have cleared browser as well as server cache too.
>>>>>>> i am getting this exception
>>>>>>>
>>>>>>> 2009-09-30 20:30:18,950 [TP-Processor3] WARN
>>>>>>> com.ecyrd.jspwiki.providers.CachingAttachmentProvider
>>>>>>>
>>>>> JSPWiki:/Wiki.jsp
>>>>>
>>>>>>> JSPWiki:https://jspwiki.prod.com/Wiki.jsp - Provider failed,
>>>>>>>
>>>>> returning
>>>>>
>>>>>>> cached content
>>>>>>> com.ecyrd.jspwiki.providers.ProviderException: Attachment
>>>>>>>
>>>>> disappeared
>>>>>
>>>>>>> while
>>>>>>> reading information: if you did not touch the repository, there is a
>>>>>>> serious
>>>>>>> bug somewhere. Attachment = AnilPanCard.jpg-dir, decoded =
>>>>>>> AnilPanCard.jpg
>>>>>>>
>>>>>>> even after changing the inlinePattern to .jpg there is no luck.
>>>>>>>
>>>>>>> access logs error but not sure this relates to this issue
>>>>>>>
>>>>>>> 2009-10-04 18:03:27,948 [TP-Processor3] ERROR
>>>>>>> org.apache.catalina.connector.CoyoteAdapter - An exception or error
>>>>>>> occurred
>>>>>>> in the container during the request processing
>>>>>>> java.lang.NullPointerException
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>>>>
>>>>>>> at
>>>>>>> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>>>>>>> at
>>>>>>> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>>>>
>>>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>>> 2009-10-04 18:03:32,448 [TP-Processor2] ERROR
>>>>>>> org.apache.catalina.connector.CoyoteAdapter - An exception or error
>>>>>>> occurred
>>>>>>> in the container during the request processing
>>>>>>> java.lang.NullPointerException
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>>>>
>>>>>>> at
>>>>>>> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>>>>>>> at
>>>>>>> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>>>>
>>>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>>>
>>>>>>>
>>>>>>> Most awaiting for you reply
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Harry Metske wrote:
>>>>>>>
>>>>>>>> Could you tell us a bit more about your configuration ?Are you
>>>>>>>>
>>>>> running
>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>> web
>>>>>>>> server in front of your container ?
>>>>>>>> Are you running Tomcat, could you share relevant entries in the
>>>>>>>>
>>>>> access
>>>>>
>>>>>>>> logs
>>>>>>>> ?
>>>>>>>> Did you clean your browser cache ?
>>>>>>>> Try to run JSPWiki with a higher debug level (see bottom of
>>>>>>>> jspwiki.properties), maybe the jspwiki.log reveals something.
>>>>>>>> Could you share your jspwiki.properties with us, how do
>>>>>>>> your jspwiki.translatorReader.inlinePattern parameters look
>>>>>>>>
>>>>> like
>>>>> ?
>>>>>
>>>>>>>> /Harry
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/10/1 anilkumarkatta <anilkumarkatta@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks again for your reply Janne.
>>>>>>>>>
>>>>>>>>> I tried with many number of times with changing the naming of the
>>>>>>>>>
>>>>> file
>>>>>
>>>>>>>>> including extention file type too..
>>>>>>>>>
>>>>>>>>> Its really a pinch for me that apart from .jpg file type..
>>>>>>>>>
>>>>> everything
>>>>>
>>>>>>>>> else
>>>>>>>>> working fine
>>>>>>>>>
>>>>>>>>> Please do advice me
>>>>>>>>>
>>>>>>>>> Thanks & Regards,
>>>>>>>>> -Anil Katta
>>>>>>>>>
>>>>>>>>> Janne Jalkanen wrote:
>>>>>>>>>
>>>>>>>>>> You still get a 404 not found? Then it's very probably a case
>>>>>>>>>>
>>>>>>> issue.
>>>>>>>
>>>>>>>>>> Try uploading a new image, and check if viewing that works. If
>>>>>>>>>>
>>>>> it
>>>>>
>>>>>>>>>> does, then it's likely that your images are in different case
>>>>>>>>>>
>>>>> than
>>>>>
>>>>>>> you
>>>>>>>
>>>>>>>>>> expect.
>>>>>>>>>>
>>>>>>>>>> For example, on Windows an image called "FOO.JPG" might
>>>>>>>>>>
>>>>> actually
>>>>>
>>>>>>> turn
>>>>>>>
>>>>>>>>>> up as "foo.jpg", because Windows has some strange
>>>>>>>>>>
>>>>> DOS-compatibility
>>>>>
>>>>>>>>>> rules.
>>>>>>>>>>
>>>>>>>>>> Please try to experiment with different images and name
>>>>>>>>>>
>>>>> formats.
>>>>>
>>>>>>>>>> Please also check that the image *really* is in the repository
>>>>>>>>>>
>>>>> and
>>>>>
>>>>>>> you
>>>>>>>
>>>>>>>>>> can open it up properly, and it's got correct permissions.
>>>>>>>>>>
>>>>> 'cos
>>>>> if
>>>>>
>>>>>>>>>> downloading works for one kind of file, it should work on all
>>>>>>>>>>
>>>>> kinds
>>>>>
>>>>>>> of
>>>>>>>
>>>>>>>>>> files, which makes me suspect it's a problem with the
>>>>>>>>>>
>>>>> particular
>>>>>
>>>>>>> files
>>>>>>>
>>>>>>>>>> you're trying to access.
>>>>>>>>>>
>>>>>>>>>> /Janne
>>>>>>>>>>
>>>>>>>>>> On Sep 30, 2009, at 10:05 , anilkumarkatta wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the Reply Janne.
>>>>>>>>>>>
>>>>>>>>>>> I took new copy of source code from the repository of the
>>>>>>>>>>>
>>>>> jspwiki,
>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>>>>> modified. Attachment filter is working fine for all other
>>>>>>>>>>> attachements like
>>>>>>>>>>> GIF,PNG, zip, bmp, etc, but it not working with .jpg file
>>>>>>>>>>>
>>>>> type.
>>>>>
>>>>>>>>>>> Please your suggesstions are most welcomed.
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> -Anil Katta
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Janne Jalkanen wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Did you check that you have the correct web.xml file? And
>>>>>>>>>>>>
>>>>> you're
>>>>>
>>>>>>> not
>>>>>>>
>>>>>>>>>>>> accidentally using the one from 2.0.x?
>>>>>>>>>>>>
>>>>>>>>>>>> /Janne
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 29, 2009, at 14:58 , anilkumarkatta wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> further
>>>>>>>>>>>>>
>>>>>>>>>>>>> when I try opening the image files through attachement tab
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://jspwiki.prodsup1.com/attach/Main/ACard.jpg
>>>>>>>>>>>>>
>>>>>>>>>>>>> it fetches me page not found
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please hlep me
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> anilkumarkatta wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Todd
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can you please give me what need to be done for this
>>>>>>>>>>>>>>
>>>>> resolution
>>>>>
>>>>>>> of
>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am facing this issue since 2 months.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> you help would be much appreciated a lot
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>> - Anil Katta
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Weis, Todd wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Duh... Forgot a backslash in directory name for
>>>>>>>>>>>>>>>
>>>>> attachments!
>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I recently upgraded from 2.05.52 to 2.8.1 and all my links
>>>>>>>>>>>>>>>
>>>>> for
>>>>>
>>>>>>> in-
>>>>>>>
>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>> attachments are broken. The files still exist, the system
>>>>>>>>>>>>>>>
>>>>>>> doesn't
>>>>>>>
>>>>>>>>>>>>>>> recognize it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Page does not recognize it has a an attachment (doesn't
>>>>>>>>>>>>>>>
>>>>> show
>>>>> up
>>>>>
>>>>>>> on
>>>>>>>
>>>>>>>>>>>>>>> attach page).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Inline images shows as broken x.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I did notice that the syntax has changed somewhat.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Old in line image
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [{Image src='james.jpg'
>>>>>>>>>>>>>>>
>>>>>>> link='attach?page=JamesPage%2Fjames.jpg'
>>>>>>>
>>>>>>>>>>>>>>> caption='James pic' alt='link to full size image' }]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> New in line:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [{Image src='james.jpg' link='attach/JamesPage/james.jpg'
>>>>>>>>>>>>>>> caption='James
>>>>>>>>>>>>>>> pic' alt='link to full size image' }]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm also not sure where it is storing the attachments in
>>>>>>>>>>>>>>>
>>>>> this
>>>>>
>>>>>>> new
>>>>>>>
>>>>>>>>>>>>>>> version.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Old version had it in a attachment directory.
>>>>>>>>>>>>>>> (shared_storage\wiki\JamesPage-att\1.jpg)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any suggestions on how to fix?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> View this message in context:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25661728.html
>>>>>
>>>>>>>>>>>>> Sent from the JspWiki - User mailing list archive at
>>>>>>>>>>>>>
>>>>> Nabble.com.
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25676020.html
>>>>>
>>>>>>>>>>> Sent from the JspWiki - User mailing list archive at
>>>>>>>>>>>
>>>>> Nabble.com.
>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>>
>>>>>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25692991.html
>>>>>
>>>>>>>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25746824.html
>>>>>
>>>>>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25765357.html
>>>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>

Re: RESOLVED: Upgrade from v2.0.52 to v2.8.1 has broken attachments

2009-10-08T09:30:09Z

BTW, what do you mean with "no luck", can't you apply the patch, can't you
reproduce, or can you reproduce, and the problem is still there....
/Harry

2009/10/8 anilkumarkatta <anilkumarkatta@...>

>
>
> No luck. :-(
>
>
> Harry Metske wrote:
> >
> > Anil,
> > can you verify/test this proposed patch ?
> > Then, please open up a JIRA issue at
> > https://issues.apache.org/jira/browse/JSPWIKI and we can take the patch
> > in.
> >
> > thanks Christoph,
> >
> > Harry
> >
> > 2009/10/7 <ctrattner@...>
> >
> >> Hi,
> >>
> >> had the same exception because of corrupted or missing prop. files.
> >> Maybe you go to BasicAttachmentProvider Line 513 und replace
> >>
> >> throw new ProviderException("Attachment disappeared while reading
> >> information:"+
> >> " if you did not
> >> touch the repository, there is a serious bug somewhere. "+
> >> "Attachment =
> >> "+attachments[i]+
> >> ", decoded =
> >> "+attachmentName );
> >>
> >> with
> >>
> >> a simple "continue" statement.
> >>
> >> This should fix the issue with messed up repos.
> >>
> >> Best Regards,
> >> Christoph
> >>
> >> ---
> >>
> >> Check out the Austria version of JSPWiki 3.0
> >> www.austria-lexikon.at(beeing opened to the public on 9th of October)
> >>
> >>
> >> Zitat von Harry Metske <harry.metske@...>:
> >>
> >>
> >> I'm out of options, I have no idea what is wrong here.
> >>> regards,
> >>> Harry
> >>>
> >>> 2009/10/6 anilkumarkatta <anilkumarkatta@...>
> >>>
> >>>
> >>>> Thank you very much for the email.
> >>>>
> >>>> These are the logs from my server
> >>>>
> >>>> 2009-10-06 20:08:40,566 [Thread-2] INFO com.ecyrd.jspwiki.WikiEngine
> -
> >>>> JSPWiki working directory is 'E:\JSPWiki\work'
> >>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
> >>>> com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are read
> >>>> from
> >>>> 'E:\JSPWiki\data'
> >>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
> >>>> com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
> >>>> E:\JSPWiki\data\OLD for storing old versions of pages
> >>>>
> >>>> I checked with the all the user permissions all looks good.
> >>>>
> >>>> all the attachement goes into the E:\jspwiki\data
> >>>> for that particular page it stores like this
> >>>> <pagename>-att\<filename>.<ext>-dir
> >>>> eg: Main-att\anil.java-dir
> >>>> in which files stored as
> >>>> <versionNo>.<ext> and attachment.properties
> >>>> eg. 1.java or 2.java and etc.
> >>>>
> >>>> Please resond with your suggestion what I do further on this.
> >>>>
> >>>> Thanks & Regards,
> >>>> -Anil Katta
> >>>>
> >>>>
> >>>> Harry Metske wrote:
> >>>> >
> >>>> > I would think there is something wrong with your pageDir and/or
> >>>> > attachmentDir.Verify your jspwiki.properties for these two props:
> >>>> >
> >>>> > jspwiki.fileSystemProvider.pageDir
> >>>> > jspwiki.basicAttachmentProvider.storageDir
> >>>> >
> >>>> > Set the loglevel to at least info, and verify if you see any errors
> >>>> during
> >>>> > startup of the wiki .
> >>>> > You should see messages like these :
> >>>> > 2009-09-24 19:26:53,813 [main] INFO
> >>>> > com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are
> >>>> read
> >>>> > from
> >>>> > '/var/jspwiki/pages'
> >>>> > 2009-09-24 19:26:53,813 [main] INFO
> >>>> > com.ecyrd.jspwiki.providers.VersioningFileProvider - Using
> directory
> >>>> > /var/jspwiki/pages/OLD for storing old versions of pages
> >>>> >
> >>>> > Also verify that the user that your wiki runs with, has read/write
> >>>> access
> >>>> > to
> >>>> > the above directories.
> >>>> > And since it looks like you are running on Windows, check the double
> >>>> > backslashes.
> >>>> >
> >>>> > If you attach a file to a page (with different suffixes) where are
> >>>> they
> >>>> > stored ?
> >>>> >
> >>>> > It really is an odd problem, I have never seen it before, so it must
> >>>> be
> >>>> an
> >>>> > environmental or configuration error somewhere.
> >>>> >
> >>>> > regards,
> >>>> > Harry
> >>>> >
> >>>> > 2009/10/5 anilkumarkatta <anilkumarkatta@...>
> >>>> >
> >>>> >>
> >>>> >> Thank you all for all replies..
> >>>> >>
> >>>> >> Yes 'm running apache web server before tomcat server.
> >>>> >> i have cleared browser as well as server cache too.
> >>>> >> i am getting this exception
> >>>> >>
> >>>> >> 2009-09-30 20:30:18,950 [TP-Processor3] WARN
> >>>> >> com.ecyrd.jspwiki.providers.CachingAttachmentProvider
> >>>> JSPWiki:/Wiki.jsp
> >>>> >> JSPWiki:https://jspwiki.prod.com/Wiki.jsp - Provider failed,
> >>>> returning
> >>>> >> cached content
> >>>> >> com.ecyrd.jspwiki.providers.ProviderException: Attachment
> >>>> disappeared
> >>>> >> while
> >>>> >> reading information: if you did not touch the repository, there is
> a
> >>>> >> serious
> >>>> >> bug somewhere. Attachment = AnilPanCard.jpg-dir, decoded =
> >>>> >> AnilPanCard.jpg
> >>>> >>
> >>>> >> even after changing the inlinePattern to .jpg there is no luck.
> >>>> >>
> >>>> >> access logs error but not sure this relates to this issue
> >>>> >>
> >>>> >> 2009-10-04 18:03:27,948 [TP-Processor3] ERROR
> >>>> >> org.apache.catalina.connector.CoyoteAdapter - An exception or error
> >>>> >> occurred
> >>>> >> in the container during the request processing
> >>>> >> java.lang.NullPointerException
> >>>> >> at
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
> >>>> >> at
> >>>> >>
> >>>>
> >>>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
> >>>> >> at
> >>>> >>
> >>>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
> >>>> >> at
> >>>> >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
> >>>> >> at
> >>>> >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
> >>>> >> at
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
> >>>> >> at
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
> >>>> >> at
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
> >>>> >> at java.lang.Thread.run(Unknown Source)
> >>>> >> 2009-10-04 18:03:32,448 [TP-Processor2] ERROR
> >>>> >> org.apache.catalina.connector.CoyoteAdapter - An exception or error
> >>>> >> occurred
> >>>> >> in the container during the request processing
> >>>> >> java.lang.NullPointerException
> >>>> >> at
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
> >>>> >> at
> >>>> >>
> >>>>
> >>>>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
> >>>> >> at
> >>>> >>
> >>>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
> >>>> >> at
> >>>> >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
> >>>> >> at
> >>>> >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
> >>>> >> at
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
> >>>> >> at
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
> >>>> >> at
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
> >>>> >> at java.lang.Thread.run(Unknown Source)
> >>>> >>
> >>>> >>
> >>>> >> Most awaiting for you reply
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> Harry Metske wrote:
> >>>> >> >
> >>>> >> > Could you tell us a bit more about your configuration ?Are you
> >>>> running
> >>>> >> a
> >>>> >> > web
> >>>> >> > server in front of your container ?
> >>>> >> > Are you running Tomcat, could you share relevant entries in the
> >>>> access
> >>>> >> > logs
> >>>> >> > ?
> >>>> >> > Did you clean your browser cache ?
> >>>> >> > Try to run JSPWiki with a higher debug level (see bottom of
> >>>> >> > jspwiki.properties), maybe the jspwiki.log reveals something.
> >>>> >> > Could you share your jspwiki.properties with us, how do
> >>>> >> > your jspwiki.translatorReader.inlinePattern parameters look
> >>>> like
> >>>> ?
> >>>> >> >
> >>>> >> > /Harry
> >>>> >> >
> >>>> >> >
> >>>> >> > 2009/10/1 anilkumarkatta <anilkumarkatta@...>
> >>>> >> >
> >>>> >> >>
> >>>> >> >> Thanks again for your reply Janne.
> >>>> >> >>
> >>>> >> >> I tried with many number of times with changing the naming of
> the
> >>>> file
> >>>> >> >> including extention file type too..
> >>>> >> >>
> >>>> >> >> Its really a pinch for me that apart from .jpg file type..
> >>>> everything
> >>>> >> >> else
> >>>> >> >> working fine
> >>>> >> >>
> >>>> >> >> Please do advice me
> >>>> >> >>
> >>>> >> >> Thanks & Regards,
> >>>> >> >> -Anil Katta
> >>>> >> >>
> >>>> >> >> Janne Jalkanen wrote:
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> > You still get a 404 not found? Then it's very probably a case
> >>>> >> issue.
> >>>> >> >> > Try uploading a new image, and check if viewing that works.
> If
> >>>> it
> >>>> >> >> > does, then it's likely that your images are in different case
> >>>> than
> >>>> >> you
> >>>> >> >> > expect.
> >>>> >> >> >
> >>>> >> >> > For example, on Windows an image called "FOO.JPG" might
> >>>> actually
> >>>> >> turn
> >>>> >> >> > up as "foo.jpg", because Windows has some strange
> >>>> DOS-compatibility
> >>>> >> >> > rules.
> >>>> >> >> >
> >>>> >> >> > Please try to experiment with different images and name
> >>>> formats.
> >>>> >> >> > Please also check that the image *really* is in the repository
> >>>> and
> >>>> >> you
> >>>> >> >> > can open it up properly, and it's got correct permissions.
> >>>> 'cos
> >>>> if
> >>>> >> >> > downloading works for one kind of file, it should work on all
> >>>> kinds
> >>>> >> of
> >>>> >> >> > files, which makes me suspect it's a problem with the
> >>>> particular
> >>>> >> files
> >>>> >> >> > you're trying to access.
> >>>> >> >> >
> >>>> >> >> > /Janne
> >>>> >> >> >
> >>>> >> >> > On Sep 30, 2009, at 10:05 , anilkumarkatta wrote:
> >>>> >> >> >
> >>>> >> >> >>
> >>>> >> >> >> Hi
> >>>> >> >> >>
> >>>> >> >> >> Thanks for the Reply Janne.
> >>>> >> >> >>
> >>>> >> >> >> I took new copy of source code from the repository of the
> >>>> jspwiki,
> >>>> >> and
> >>>> >> >> >> modified. Attachment filter is working fine for all other
> >>>> >> >> >> attachements like
> >>>> >> >> >> GIF,PNG, zip, bmp, etc, but it not working with .jpg file
> >>>> type.
> >>>> >> >> >>
> >>>> >> >> >> Please your suggesstions are most welcomed.
> >>>> >> >> >>
> >>>> >> >> >> Thanks & Regards,
> >>>> >> >> >> -Anil Katta
> >>>> >> >> >>
> >>>> >> >> >>
> >>>> >> >> >> Janne Jalkanen wrote:
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>> Did you check that you have the correct web.xml file? And
> >>>> you're
> >>>> >> not
> >>>> >> >> >>> accidentally using the one from 2.0.x?
> >>>> >> >> >>>
> >>>> >> >> >>> /Janne
> >>>> >> >> >>>
> >>>> >> >> >>> On Sep 29, 2009, at 14:58 , anilkumarkatta wrote:
> >>>> >> >> >>>
> >>>> >> >> >>>>
> >>>> >> >> >>>> further
> >>>> >> >> >>>>
> >>>> >> >> >>>> when I try opening the image files through attachement tab
> >>>> >> >> >>>>
> >>>> >> >> >>>> https://jspwiki.prodsup1.com/attach/Main/ACard.jpg
> >>>> >> >> >>>>
> >>>> >> >> >>>> it fetches me page not found
> >>>> >> >> >>>>
> >>>> >> >> >>>> Please hlep me
> >>>> >> >> >>>>
> >>>> >> >> >>>>
> >>>> >> >> >>>> anilkumarkatta wrote:
> >>>> >> >> >>>>>
> >>>> >> >> >>>>> Hi Todd
> >>>> >> >> >>>>>
> >>>> >> >> >>>>> Can you please give me what need to be done for this
> >>>> resolution
> >>>> >> of
> >>>> >> >> >>>>> the
> >>>> >> >> >>>>> issue.
> >>>> >> >> >>>>>
> >>>> >> >> >>>>> I am facing this issue since 2 months.
> >>>> >> >> >>>>>
> >>>> >> >> >>>>> you help would be much appreciated a lot
> >>>> >> >> >>>>>
> >>>> >> >> >>>>> Thanks & Regards,
> >>>> >> >> >>>>> - Anil Katta
> >>>> >> >> >>>>>
> >>>> >> >> >>>>>
> >>>> >> >> >>>>> Weis, Todd wrote:
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> Duh... Forgot a backslash in directory name for
> >>>> attachments!
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> -----Original Message-----
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> I recently upgraded from 2.05.52 to 2.8.1 and all my
> links
> >>>> for
> >>>> >> in-
> >>>> >> >> >>>>>> line
> >>>> >> >> >>>>>> attachments are broken. The files still exist, the
> system
> >>>> >> doesn't
> >>>> >> >> >>>>>> recognize it.
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> Page does not recognize it has a an attachment (doesn't
> >>>> show
> >>>> up
> >>>> >> on
> >>>> >> >> >>>>>> attach page).
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> Inline images shows as broken x.
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> I did notice that the syntax has changed somewhat.
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> Old in line image
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> [{Image src='james.jpg'
> >>>> >> link='attach?page=JamesPage%2Fjames.jpg'
> >>>> >> >> >>>>>> caption='James pic' alt='link to full size image' }]
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> New in line:
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> [{Image src='james.jpg' link='attach/JamesPage/james.jpg'
> >>>> >> >> >>>>>> caption='James
> >>>> >> >> >>>>>> pic' alt='link to full size image' }]
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> I'm also not sure where it is storing the attachments in
> >>>> this
> >>>> >> new
> >>>> >> >> >>>>>> version.
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> Old version had it in a attachment directory.
> >>>> >> >> >>>>>> (shared_storage\wiki\JamesPage-att\1.jpg)
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>> Any suggestions on how to fix?
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>>
> >>>> >> >> >>>>>
> >>>> >> >> >>>>>
> >>>> >> >> >>>>
> >>>> >> >> >>>> --
> >>>> >> >> >>>> View this message in context:
> >>>> >> >> >>>>
> >>>> >> >>
> >>>> >>
> >>>>
> >>>>
> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25661728.html
> >>>> >> >> >>>> Sent from the JspWiki - User mailing list archive at
> >>>> Nabble.com.
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>>
> >>>> >> >> >>
> >>>> >> >> >> --
> >>>> >> >> >> View this message in context:
> >>>> >> >> >>
> >>>> >> >>
> >>>> >>
> >>>>
> >>>>
> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25676020.html
> >>>> >> >> >> Sent from the JspWiki - User mailing list archive at
> >>>> Nabble.com.
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >>
> >>>> >> >> --
> >>>> >> >> View this message in context:
> >>>> >> >>
> >>>> >>
> >>>>
> >>>>
> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25692991.html
> >>>> >> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>>> >> >>
> >>>> >> >>
> >>>> >> >
> >>>> >> >
> >>>> >>
> >>>> >> --
> >>>> >> View this message in context:
> >>>> >>
> >>>>
> >>>>
> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25746824.html
> >>>> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>>> >>
> >>>> >>
> >>>> >
> >>>> >
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>>
> >>>>
> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25765357.html
> >>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25800163.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.
>
>

Re: RESOLVED: Upgrade from v2.0.52 to v2.8.1 has broken attachments

2009-10-08T01:34:21Z

Can you provide information about your log output here?

best,
christoph

anilkumarkatta schrieb:

> No luck. :-(
>
>
> Harry Metske wrote:
>
>> Anil,
>> can you verify/test this proposed patch ?
>> Then, please open up a JIRA issue at
>> https://issues.apache.org/jira/browse/JSPWIKI and we can take the patch
>> in.
>>
>> thanks Christoph,
>>
>> Harry
>>
>> 2009/10/7 <ctrattner@...>
>>
>>
>>> Hi,
>>>
>>> had the same exception because of corrupted or missing prop. files.
>>> Maybe you go to BasicAttachmentProvider Line 513 und replace
>>>
>>> throw new ProviderException("Attachment disappeared while reading
>>> information:"+
>>> " if you did not
>>> touch the repository, there is a serious bug somewhere. "+
>>> "Attachment =
>>> "+attachments[i]+
>>> ", decoded =
>>> "+attachmentName );
>>>
>>> with
>>>
>>> a simple "continue" statement.
>>>
>>> This should fix the issue with messed up repos.
>>>
>>> Best Regards,
>>> Christoph
>>>
>>> ---
>>>
>>> Check out the Austria version of JSPWiki 3.0
>>> www.austria-lexikon.at(beeing opened to the public on 9th of October)
>>>
>>>
>>> Zitat von Harry Metske <harry.metske@...>:
>>>
>>>
>>> I'm out of options, I have no idea what is wrong here.
>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2009/10/6 anilkumarkatta <anilkumarkatta@...>
>>>>
>>>>
>>>>
>>>>> Thank you very much for the email.
>>>>>
>>>>> These are the logs from my server
>>>>>
>>>>> 2009-10-06 20:08:40,566 [Thread-2] INFO com.ecyrd.jspwiki.WikiEngine -
>>>>> JSPWiki working directory is 'E:\JSPWiki\work'
>>>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
>>>>> com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are read
>>>>> from
>>>>> 'E:\JSPWiki\data'
>>>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
>>>>> com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
>>>>> E:\JSPWiki\data\OLD for storing old versions of pages
>>>>>
>>>>> I checked with the all the user permissions all looks good.
>>>>>
>>>>> all the attachement goes into the E:\jspwiki\data
>>>>> for that particular page it stores like this
>>>>> <pagename>-att\<filename>.<ext>-dir
>>>>> eg: Main-att\anil.java-dir
>>>>> in which files stored as
>>>>> <versionNo>.<ext> and attachment.properties
>>>>> eg. 1.java or 2.java and etc.
>>>>>
>>>>> Please resond with your suggestion what I do further on this.
>>>>>
>>>>> Thanks & Regards,
>>>>> -Anil Katta
>>>>>
>>>>>
>>>>> Harry Metske wrote:
>>>>>
>>>>>> I would think there is something wrong with your pageDir and/or
>>>>>> attachmentDir.Verify your jspwiki.properties for these two props:
>>>>>>
>>>>>> jspwiki.fileSystemProvider.pageDir
>>>>>> jspwiki.basicAttachmentProvider.storageDir
>>>>>>
>>>>>> Set the loglevel to at least info, and verify if you see any errors
>>>>>>
>>>>> during
>>>>>
>>>>>> startup of the wiki .
>>>>>> You should see messages like these :
>>>>>> 2009-09-24 19:26:53,813 [main] INFO
>>>>>> com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are
>>>>>>
>>>>> read
>>>>>
>>>>>> from
>>>>>> '/var/jspwiki/pages'
>>>>>> 2009-09-24 19:26:53,813 [main] INFO
>>>>>> com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
>>>>>> /var/jspwiki/pages/OLD for storing old versions of pages
>>>>>>
>>>>>> Also verify that the user that your wiki runs with, has read/write
>>>>>>
>>>>> access
>>>>>
>>>>>> to
>>>>>> the above directories.
>>>>>> And since it looks like you are running on Windows, check the double
>>>>>> backslashes.
>>>>>>
>>>>>> If you attach a file to a page (with different suffixes) where are
>>>>>>
>>>>> they
>>>>>
>>>>>> stored ?
>>>>>>
>>>>>> It really is an odd problem, I have never seen it before, so it must
>>>>>>
>>>>> be
>>>>> an
>>>>>
>>>>>> environmental or configuration error somewhere.
>>>>>>
>>>>>> regards,
>>>>>> Harry
>>>>>>
>>>>>> 2009/10/5 anilkumarkatta <anilkumarkatta@...>
>>>>>>
>>>>>>
>>>>>>> Thank you all for all replies..
>>>>>>>
>>>>>>> Yes 'm running apache web server before tomcat server.
>>>>>>> i have cleared browser as well as server cache too.
>>>>>>> i am getting this exception
>>>>>>>
>>>>>>> 2009-09-30 20:30:18,950 [TP-Processor3] WARN
>>>>>>> com.ecyrd.jspwiki.providers.CachingAttachmentProvider
>>>>>>>
>>>>> JSPWiki:/Wiki.jsp
>>>>>
>>>>>>> JSPWiki:https://jspwiki.prod.com/Wiki.jsp - Provider failed,
>>>>>>>
>>>>> returning
>>>>>
>>>>>>> cached content
>>>>>>> com.ecyrd.jspwiki.providers.ProviderException: Attachment
>>>>>>>
>>>>> disappeared
>>>>>
>>>>>>> while
>>>>>>> reading information: if you did not touch the repository, there is a
>>>>>>> serious
>>>>>>> bug somewhere. Attachment = AnilPanCard.jpg-dir, decoded =
>>>>>>> AnilPanCard.jpg
>>>>>>>
>>>>>>> even after changing the inlinePattern to .jpg there is no luck.
>>>>>>>
>>>>>>> access logs error but not sure this relates to this issue
>>>>>>>
>>>>>>> 2009-10-04 18:03:27,948 [TP-Processor3] ERROR
>>>>>>> org.apache.catalina.connector.CoyoteAdapter - An exception or error
>>>>>>> occurred
>>>>>>> in the container during the request processing
>>>>>>> java.lang.NullPointerException
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>>>>
>>>>>>> at
>>>>>>> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>>>>>>> at
>>>>>>> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>>>>
>>>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>>> 2009-10-04 18:03:32,448 [TP-Processor2] ERROR
>>>>>>> org.apache.catalina.connector.CoyoteAdapter - An exception or error
>>>>>>> occurred
>>>>>>> in the container during the request processing
>>>>>>> java.lang.NullPointerException
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>>>>
>>>>>>> at
>>>>>>> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>>>>>>> at
>>>>>>> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>>>>
>>>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>>>
>>>>>>>
>>>>>>> Most awaiting for you reply
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Harry Metske wrote:
>>>>>>>
>>>>>>>> Could you tell us a bit more about your configuration ?Are you
>>>>>>>>
>>>>> running
>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>> web
>>>>>>>> server in front of your container ?
>>>>>>>> Are you running Tomcat, could you share relevant entries in the
>>>>>>>>
>>>>> access
>>>>>
>>>>>>>> logs
>>>>>>>> ?
>>>>>>>> Did you clean your browser cache ?
>>>>>>>> Try to run JSPWiki with a higher debug level (see bottom of
>>>>>>>> jspwiki.properties), maybe the jspwiki.log reveals something.
>>>>>>>> Could you share your jspwiki.properties with us, how do
>>>>>>>> your jspwiki.translatorReader.inlinePattern parameters look
>>>>>>>>
>>>>> like
>>>>> ?
>>>>>
>>>>>>>> /Harry
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/10/1 anilkumarkatta <anilkumarkatta@...>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks again for your reply Janne.
>>>>>>>>>
>>>>>>>>> I tried with many number of times with changing the naming of the
>>>>>>>>>
>>>>> file
>>>>>
>>>>>>>>> including extention file type too..
>>>>>>>>>
>>>>>>>>> Its really a pinch for me that apart from .jpg file type..
>>>>>>>>>
>>>>> everything
>>>>>
>>>>>>>>> else
>>>>>>>>> working fine
>>>>>>>>>
>>>>>>>>> Please do advice me
>>>>>>>>>
>>>>>>>>> Thanks & Regards,
>>>>>>>>> -Anil Katta
>>>>>>>>>
>>>>>>>>> Janne Jalkanen wrote:
>>>>>>>>>
>>>>>>>>>> You still get a 404 not found? Then it's very probably a case
>>>>>>>>>>
>>>>>>> issue.
>>>>>>>
>>>>>>>>>> Try uploading a new image, and check if viewing that works. If
>>>>>>>>>>
>>>>> it
>>>>>
>>>>>>>>>> does, then it's likely that your images are in different case
>>>>>>>>>>
>>>>> than
>>>>>
>>>>>>> you
>>>>>>>
>>>>>>>>>> expect.
>>>>>>>>>>
>>>>>>>>>> For example, on Windows an image called "FOO.JPG" might
>>>>>>>>>>
>>>>> actually
>>>>>
>>>>>>> turn
>>>>>>>
>>>>>>>>>> up as "foo.jpg", because Windows has some strange
>>>>>>>>>>
>>>>> DOS-compatibility
>>>>>
>>>>>>>>>> rules.
>>>>>>>>>>
>>>>>>>>>> Please try to experiment with different images and name
>>>>>>>>>>
>>>>> formats.
>>>>>
>>>>>>>>>> Please also check that the image *really* is in the repository
>>>>>>>>>>
>>>>> and
>>>>>
>>>>>>> you
>>>>>>>
>>>>>>>>>> can open it up properly, and it's got correct permissions.
>>>>>>>>>>
>>>>> 'cos
>>>>> if
>>>>>
>>>>>>>>>> downloading works for one kind of file, it should work on all
>>>>>>>>>>
>>>>> kinds
>>>>>
>>>>>>> of
>>>>>>>
>>>>>>>>>> files, which makes me suspect it's a problem with the
>>>>>>>>>>
>>>>> particular
>>>>>
>>>>>>> files
>>>>>>>
>>>>>>>>>> you're trying to access.
>>>>>>>>>>
>>>>>>>>>> /Janne
>>>>>>>>>>
>>>>>>>>>> On Sep 30, 2009, at 10:05 , anilkumarkatta wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the Reply Janne.
>>>>>>>>>>>
>>>>>>>>>>> I took new copy of source code from the repository of the
>>>>>>>>>>>
>>>>> jspwiki,
>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>>>>> modified. Attachment filter is working fine for all other
>>>>>>>>>>> attachements like
>>>>>>>>>>> GIF,PNG, zip, bmp, etc, but it not working with .jpg file
>>>>>>>>>>>
>>>>> type.
>>>>>
>>>>>>>>>>> Please your suggesstions are most welcomed.
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> -Anil Katta
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Janne Jalkanen wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Did you check that you have the correct web.xml file? And
>>>>>>>>>>>>
>>>>> you're
>>>>>
>>>>>>> not
>>>>>>>
>>>>>>>>>>>> accidentally using the one from 2.0.x?
>>>>>>>>>>>>
>>>>>>>>>>>> /Janne
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 29, 2009, at 14:58 , anilkumarkatta wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> further
>>>>>>>>>>>>>
>>>>>>>>>>>>> when I try opening the image files through attachement tab
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://jspwiki.prodsup1.com/attach/Main/ACard.jpg
>>>>>>>>>>>>>
>>>>>>>>>>>>> it fetches me page not found
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please hlep me
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> anilkumarkatta wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Todd
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can you please give me what need to be done for this
>>>>>>>>>>>>>>
>>>>> resolution
>>>>>
>>>>>>> of
>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am facing this issue since 2 months.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> you help would be much appreciated a lot
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>> - Anil Katta
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Weis, Todd wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Duh... Forgot a backslash in directory name for
>>>>>>>>>>>>>>>
>>>>> attachments!
>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I recently upgraded from 2.05.52 to 2.8.1 and all my links
>>>>>>>>>>>>>>>
>>>>> for
>>>>>
>>>>>>> in-
>>>>>>>
>>>>>>>>>>>>>>> line
>>>>>>>>>>>>>>> attachments are broken. The files still exist, the system
>>>>>>>>>>>>>>>
>>>>>>> doesn't
>>>>>>>
>>>>>>>>>>>>>>> recognize it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Page does not recognize it has a an attachment (doesn't
>>>>>>>>>>>>>>>
>>>>> show
>>>>> up
>>>>>
>>>>>>> on
>>>>>>>
>>>>>>>>>>>>>>> attach page).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Inline images shows as broken x.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I did notice that the syntax has changed somewhat.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Old in line image
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [{Image src='james.jpg'
>>>>>>>>>>>>>>>
>>>>>>> link='attach?page=JamesPage%2Fjames.jpg'
>>>>>>>
>>>>>>>>>>>>>>> caption='James pic' alt='link to full size image' }]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> New in line:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [{Image src='james.jpg' link='attach/JamesPage/james.jpg'
>>>>>>>>>>>>>>> caption='James
>>>>>>>>>>>>>>> pic' alt='link to full size image' }]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm also not sure where it is storing the attachments in
>>>>>>>>>>>>>>>
>>>>> this
>>>>>
>>>>>>> new
>>>>>>>
>>>>>>>>>>>>>>> version.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Old version had it in a attachment directory.
>>>>>>>>>>>>>>> (shared_storage\wiki\JamesPage-att\1.jpg)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any suggestions on how to fix?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> View this message in context:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25661728.html
>>>>>
>>>>>>>>>>>>> Sent from the JspWiki - User mailing list archive at
>>>>>>>>>>>>>
>>>>> Nabble.com.
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25676020.html
>>>>>
>>>>>>>>>>> Sent from the JspWiki - User mailing list archive at
>>>>>>>>>>>
>>>>> Nabble.com.
>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>>
>>>>>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25692991.html
>>>>>
>>>>>>>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25746824.html
>>>>>
>>>>>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25765357.html
>>>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>

Re: RESOLVED: Upgrade from v2.0.52 to v2.8.1 has broken attachments

2009-10-08T01:22:10Z

No luck. :-(

Harry Metske wrote:

Anil,
can you verify/test this proposed patch ?
Then, please open up a JIRA issue at
https://issues.apache.org/jira/browse/JSPWIKI and we can take the patch in.

thanks Christoph,

Harry

2009/10/7 <ctrattner@iicm.edu>

> Hi,
>
> had the same exception because of corrupted or missing prop. files.
> Maybe you go to BasicAttachmentProvider Line 513 und replace
>
> throw new ProviderException("Attachment disappeared while reading
> information:"+
> " if you did not
> touch the repository, there is a serious bug somewhere. "+
> "Attachment =
> "+attachments[i]+
> ", decoded =
> "+attachmentName );
>
> with
>
> a simple "continue" statement.
>
> This should fix the issue with messed up repos.
>
> Best Regards,
> Christoph
>
> ---
>
> Check out the Austria version of JSPWiki 3.0 www.austria-lexikon.at(beeing opened to the public on 9th of October)
>
>
> Zitat von Harry Metske <harry.metske@gmail.com>:
>
>
> I'm out of options, I have no idea what is wrong here.
>> regards,
>> Harry
>>
>> 2009/10/6 anilkumarkatta <anilkumarkatta@gmail.com>
>>
>>
>>> Thank you very much for the email.
>>>
>>> These are the logs from my server
>>>
>>> 2009-10-06 20:08:40,566 [Thread-2] INFO com.ecyrd.jspwiki.WikiEngine -
>>> JSPWiki working directory is 'E:\JSPWiki\work'
>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
>>> com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are read
>>> from
>>> 'E:\JSPWiki\data'
>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
>>> com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
>>> E:\JSPWiki\data\OLD for storing old versions of pages
>>>
>>> I checked with the all the user permissions all looks good.
>>>
>>> all the attachement goes into the E:\jspwiki\data
>>> for that particular page it stores like this
>>> <pagename>-att\<filename>.<ext>-dir
>>> eg: Main-att\anil.java-dir
>>> in which files stored as
>>> <versionNo>.<ext> and attachment.properties
>>> eg. 1.java or 2.java and etc.
>>>
>>> Please resond with your suggestion what I do further on this.
>>>
>>> Thanks & Regards,
>>> -Anil Katta
>>>
>>>
>>> Harry Metske wrote:
>>> >
>>> > I would think there is something wrong with your pageDir and/or
>>> > attachmentDir.Verify your jspwiki.properties for these two props:
>>> >
>>> > jspwiki.fileSystemProvider.pageDir
>>> > jspwiki.basicAttachmentProvider.storageDir
>>> >
>>> > Set the loglevel to at least info, and verify if you see any errors
>>> during
>>> > startup of the wiki .
>>> > You should see messages like these :
>>> > 2009-09-24 19:26:53,813 [main] INFO
>>> > com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are read
>>> > from
>>> > '/var/jspwiki/pages'
>>> > 2009-09-24 19:26:53,813 [main] INFO
>>> > com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
>>> > /var/jspwiki/pages/OLD for storing old versions of pages
>>> >
>>> > Also verify that the user that your wiki runs with, has read/write
>>> access
>>> > to
>>> > the above directories.
>>> > And since it looks like you are running on Windows, check the double
>>> > backslashes.
>>> >
>>> > If you attach a file to a page (with different suffixes) where are they
>>> > stored ?
>>> >
>>> > It really is an odd problem, I have never seen it before, so it must be
>>> an
>>> > environmental or configuration error somewhere.
>>> >
>>> > regards,
>>> > Harry
>>> >
>>> > 2009/10/5 anilkumarkatta <anilkumarkatta@gmail.com>
>>> >
>>> >>
>>> >> Thank you all for all replies..
>>> >>
>>> >> Yes 'm running apache web server before tomcat server.
>>> >> i have cleared browser as well as server cache too.
>>> >> i am getting this exception
>>> >>
>>> >> 2009-09-30 20:30:18,950 [TP-Processor3] WARN
>>> >> com.ecyrd.jspwiki.providers.CachingAttachmentProvider
>>> JSPWiki:/Wiki.jsp
>>> >> JSPWiki:https://jspwiki.prod.com/Wiki.jsp - Provider failed,
>>> returning
>>> >> cached content
>>> >> com.ecyrd.jspwiki.providers.ProviderException: Attachment disappeared
>>> >> while
>>> >> reading information: if you did not touch the repository, there is a
>>> >> serious
>>> >> bug somewhere. Attachment = AnilPanCard.jpg-dir, decoded =
>>> >> AnilPanCard.jpg
>>> >>
>>> >> even after changing the inlinePattern to .jpg there is no luck.
>>> >>
>>> >> access logs error but not sure this relates to this issue
>>> >>
>>> >> 2009-10-04 18:03:27,948 [TP-Processor3] ERROR
>>> >> org.apache.catalina.connector.CoyoteAdapter - An exception or error
>>> >> occurred
>>> >> in the container during the request processing
>>> >> java.lang.NullPointerException
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
>>> >> at
>>> >>
>>>
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>> >> at
>>> >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>> >> at
>>> >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>>> >> at
>>> >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>> >> at java.lang.Thread.run(Unknown Source)
>>> >> 2009-10-04 18:03:32,448 [TP-Processor2] ERROR
>>> >> org.apache.catalina.connector.CoyoteAdapter - An exception or error
>>> >> occurred
>>> >> in the container during the request processing
>>> >> java.lang.NullPointerException
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
>>> >> at
>>> >>
>>>
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>> >> at
>>> >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>> >> at
>>> >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>>> >> at
>>> >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>> >> at java.lang.Thread.run(Unknown Source)
>>> >>
>>> >>
>>> >> Most awaiting for you reply
>>> >>
>>> >>
>>> >>
>>> >> Harry Metske wrote:
>>> >> >
>>> >> > Could you tell us a bit more about your configuration ?Are you
>>> running
>>> >> a
>>> >> > web
>>> >> > server in front of your container ?
>>> >> > Are you running Tomcat, could you share relevant entries in the
>>> access
>>> >> > logs
>>> >> > ?
>>> >> > Did you clean your browser cache ?
>>> >> > Try to run JSPWiki with a higher debug level (see bottom of
>>> >> > jspwiki.properties), maybe the jspwiki.log reveals something.
>>> >> > Could you share your jspwiki.properties with us, how do
>>> >> > your jspwiki.translatorReader.inlinePattern parameters look like
>>> ?
>>> >> >
>>> >> > /Harry
>>> >> >
>>> >> >
>>> >> > 2009/10/1 anilkumarkatta <anilkumarkatta@gmail.com>
>>> >> >
>>> >> >>
>>> >> >> Thanks again for your reply Janne.
>>> >> >>
>>> >> >> I tried with many number of times with changing the naming of the
>>> file
>>> >> >> including extention file type too..
>>> >> >>
>>> >> >> Its really a pinch for me that apart from .jpg file type..
>>> everything
>>> >> >> else
>>> >> >> working fine
>>> >> >>
>>> >> >> Please do advice me
>>> >> >>
>>> >> >> Thanks & Regards,
>>> >> >> -Anil Katta
>>> >> >>
>>> >> >> Janne Jalkanen wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> > You still get a 404 not found? Then it's very probably a case
>>> >> issue.
>>> >> >> > Try uploading a new image, and check if viewing that works. If
>>> it
>>> >> >> > does, then it's likely that your images are in different case
>>> than
>>> >> you
>>> >> >> > expect.
>>> >> >> >
>>> >> >> > For example, on Windows an image called "FOO.JPG" might actually
>>> >> turn
>>> >> >> > up as "foo.jpg", because Windows has some strange
>>> DOS-compatibility
>>> >> >> > rules.
>>> >> >> >
>>> >> >> > Please try to experiment with different images and name formats.
>>> >> >> > Please also check that the image *really* is in the repository
>>> and
>>> >> you
>>> >> >> > can open it up properly, and it's got correct permissions. 'cos
>>> if
>>> >> >> > downloading works for one kind of file, it should work on all
>>> kinds
>>> >> of
>>> >> >> > files, which makes me suspect it's a problem with the particular
>>> >> files
>>> >> >> > you're trying to access.
>>> >> >> >
>>> >> >> > /Janne
>>> >> >> >
>>> >> >> > On Sep 30, 2009, at 10:05 , anilkumarkatta wrote:
>>> >> >> >
>>> >> >> >>
>>> >> >> >> Hi
>>> >> >> >>
>>> >> >> >> Thanks for the Reply Janne.
>>> >> >> >>
>>> >> >> >> I took new copy of source code from the repository of the
>>> jspwiki,
>>> >> and
>>> >> >> >> modified. Attachment filter is working fine for all other
>>> >> >> >> attachements like
>>> >> >> >> GIF,PNG, zip, bmp, etc, but it not working with .jpg file type.
>>> >> >> >>
>>> >> >> >> Please your suggesstions are most welcomed.
>>> >> >> >>
>>> >> >> >> Thanks & Regards,
>>> >> >> >> -Anil Katta
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> Janne Jalkanen wrote:
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> Did you check that you have the correct web.xml file? And
>>> you're
>>> >> not
>>> >> >> >>> accidentally using the one from 2.0.x?
>>> >> >> >>>
>>> >> >> >>> /Janne
>>> >> >> >>>
>>> >> >> >>> On Sep 29, 2009, at 14:58 , anilkumarkatta wrote:
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>> further
>>> >> >> >>>>
>>> >> >> >>>> when I try opening the image files through attachement tab
>>> >> >> >>>>
>>> >> >> >>>> https://jspwiki.prodsup1.com/attach/Main/ACard.jpg
>>> >> >> >>>>
>>> >> >> >>>> it fetches me page not found
>>> >> >> >>>>
>>> >> >> >>>> Please hlep me
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>> anilkumarkatta wrote:
>>> >> >> >>>>>
>>> >> >> >>>>> Hi Todd
>>> >> >> >>>>>
>>> >> >> >>>>> Can you please give me what need to be done for this
>>> resolution
>>> >> of
>>> >> >> >>>>> the
>>> >> >> >>>>> issue.
>>> >> >> >>>>>
>>> >> >> >>>>> I am facing this issue since 2 months.
>>> >> >> >>>>>
>>> >> >> >>>>> you help would be much appreciated a lot
>>> >> >> >>>>>
>>> >> >> >>>>> Thanks & Regards,
>>> >> >> >>>>> - Anil Katta
>>> >> >> >>>>>
>>> >> >> >>>>>
>>> >> >> >>>>> Weis, Todd wrote:
>>> >> >> >>>>>>
>>> >> >> >>>>>> Duh... Forgot a backslash in directory name for
>>> attachments!
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> -----Original Message-----
>>> >> >> >>>>>>
>>> >> >> >>>>>> I recently upgraded from 2.05.52 to 2.8.1 and all my links
>>> for
>>> >> in-
>>> >> >> >>>>>> line
>>> >> >> >>>>>> attachments are broken. The files still exist, the system
>>> >> doesn't
>>> >> >> >>>>>> recognize it.
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> Page does not recognize it has a an attachment (doesn't show
>>> up
>>> >> on
>>> >> >> >>>>>> attach page).
>>> >> >> >>>>>>
>>> >> >> >>>>>> Inline images shows as broken x.
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> I did notice that the syntax has changed somewhat.
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> Old in line image
>>> >> >> >>>>>>
>>> >> >> >>>>>> [{Image src='james.jpg'
>>> >> link='attach?page=JamesPage%2Fjames.jpg'
>>> >> >> >>>>>> caption='James pic' alt='link to full size image' }]
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> New in line:
>>> >> >> >>>>>>
>>> >> >> >>>>>> [{Image src='james.jpg' link='attach/JamesPage/james.jpg'
>>> >> >> >>>>>> caption='James
>>> >> >> >>>>>> pic' alt='link to full size image' }]
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> I'm also not sure where it is storing the attachments in
>>> this
>>> >> new
>>> >> >> >>>>>> version.
>>> >> >> >>>>>>
>>> >> >> >>>>>> Old version had it in a attachment directory.
>>> >> >> >>>>>> (shared_storage\wiki\JamesPage-att\1.jpg)
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> Any suggestions on how to fix?
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>
>>> >> >> >>>>>
>>> >> >> >>>>
>>> >> >> >>>> --
>>> >> >> >>>> View this message in context:
>>> >> >> >>>>
>>> >> >>
>>> >>
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25661728.html
>>> >> >> >>>> Sent from the JspWiki - User mailing list archive at
>>> Nabble.com.
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> View this message in context:
>>> >> >> >>
>>> >> >>
>>> >>
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25676020.html
>>> >> >> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >> --
>>> >> >> View this message in context:
>>> >> >>
>>> >>
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25692991.html
>>> >> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25746824.html
>>> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25765357.html
>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>>
>
>
>

Re: RESOLVED: Upgrade from v2.0.52 to v2.8.1 has broken attachments

2009-10-07T11:09:32Z

Anil,
can you verify/test this proposed patch ?
Then, please open up a JIRA issue at
https://issues.apache.org/jira/browse/JSPWIKI and we can take the patch in.

thanks Christoph,

Harry

2009/10/7 <ctrattner@...>

> Hi,
>
> had the same exception because of corrupted or missing prop. files.
> Maybe you go to BasicAttachmentProvider Line 513 und replace
>
> throw new ProviderException("Attachment disappeared while reading
> information:"+
> " if you did not
> touch the repository, there is a serious bug somewhere. "+
> "Attachment =
> "+attachments[i]+
> ", decoded =
> "+attachmentName );
>
> with
>
> a simple "continue" statement.
>
> This should fix the issue with messed up repos.
>
> Best Regards,
> Christoph
>
> ---
>
> Check out the Austria version of JSPWiki 3.0 www.austria-lexikon.at(beeing opened to the public on 9th of October)
>
>
> Zitat von Harry Metske <harry.metske@...>:
>
>
> I'm out of options, I have no idea what is wrong here.
>> regards,
>> Harry
>>
>> 2009/10/6 anilkumarkatta <anilkumarkatta@...>
>>
>>
>>> Thank you very much for the email.
>>>
>>> These are the logs from my server
>>>
>>> 2009-10-06 20:08:40,566 [Thread-2] INFO com.ecyrd.jspwiki.WikiEngine -
>>> JSPWiki working directory is 'E:\JSPWiki\work'
>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
>>> com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are read
>>> from
>>> 'E:\JSPWiki\data'
>>> 2009-10-06 20:08:40,925 [Thread-2] INFO
>>> com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
>>> E:\JSPWiki\data\OLD for storing old versions of pages
>>>
>>> I checked with the all the user permissions all looks good.
>>>
>>> all the attachement goes into the E:\jspwiki\data
>>> for that particular page it stores like this
>>> <pagename>-att\<filename>.<ext>-dir
>>> eg: Main-att\anil.java-dir
>>> in which files stored as
>>> <versionNo>.<ext> and attachment.properties
>>> eg. 1.java or 2.java and etc.
>>>
>>> Please resond with your suggestion what I do further on this.
>>>
>>> Thanks & Regards,
>>> -Anil Katta
>>>
>>>
>>> Harry Metske wrote:
>>> >
>>> > I would think there is something wrong with your pageDir and/or
>>> > attachmentDir.Verify your jspwiki.properties for these two props:
>>> >
>>> > jspwiki.fileSystemProvider.pageDir
>>> > jspwiki.basicAttachmentProvider.storageDir
>>> >
>>> > Set the loglevel to at least info, and verify if you see any errors
>>> during
>>> > startup of the wiki .
>>> > You should see messages like these :
>>> > 2009-09-24 19:26:53,813 [main] INFO
>>> > com.ecyrd.jspwiki.providers.AbstractFileProvider - Wikipages are read
>>> > from
>>> > '/var/jspwiki/pages'
>>> > 2009-09-24 19:26:53,813 [main] INFO
>>> > com.ecyrd.jspwiki.providers.VersioningFileProvider - Using directory
>>> > /var/jspwiki/pages/OLD for storing old versions of pages
>>> >
>>> > Also verify that the user that your wiki runs with, has read/write
>>> access
>>> > to
>>> > the above directories.
>>> > And since it looks like you are running on Windows, check the double
>>> > backslashes.
>>> >
>>> > If you attach a file to a page (with different suffixes) where are they
>>> > stored ?
>>> >
>>> > It really is an odd problem, I have never seen it before, so it must be
>>> an
>>> > environmental or configuration error somewhere.
>>> >
>>> > regards,
>>> > Harry
>>> >
>>> > 2009/10/5 anilkumarkatta <anilkumarkatta@...>
>>> >
>>> >>
>>> >> Thank you all for all replies..
>>> >>
>>> >> Yes 'm running apache web server before tomcat server.
>>> >> i have cleared browser as well as server cache too.
>>> >> i am getting this exception
>>> >>
>>> >> 2009-09-30 20:30:18,950 [TP-Processor3] WARN
>>> >> com.ecyrd.jspwiki.providers.CachingAttachmentProvider
>>> JSPWiki:/Wiki.jsp
>>> >> JSPWiki:https://jspwiki.prod.com/Wiki.jsp - Provider failed,
>>> returning
>>> >> cached content
>>> >> com.ecyrd.jspwiki.providers.ProviderException: Attachment disappeared
>>> >> while
>>> >> reading information: if you did not touch the repository, there is a
>>> >> serious
>>> >> bug somewhere. Attachment = AnilPanCard.jpg-dir, decoded =
>>> >> AnilPanCard.jpg
>>> >>
>>> >> even after changing the inlinePattern to .jpg there is no luck.
>>> >>
>>> >> access logs error but not sure this relates to this issue
>>> >>
>>> >> 2009-10-04 18:03:27,948 [TP-Processor3] ERROR
>>> >> org.apache.catalina.connector.CoyoteAdapter - An exception or error
>>> >> occurred
>>> >> in the container during the request processing
>>> >> java.lang.NullPointerException
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
>>> >> at
>>> >>
>>>
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>> >> at
>>> >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>> >> at
>>> >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>>> >> at
>>> >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>> >> at java.lang.Thread.run(Unknown Source)
>>> >> 2009-10-04 18:03:32,448 [TP-Processor2] ERROR
>>> >> org.apache.catalina.connector.CoyoteAdapter - An exception or error
>>> >> occurred
>>> >> in the container during the request processing
>>> >> java.lang.NullPointerException
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:348)
>>> >> at
>>> >>
>>>
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>> >> at
>>> >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>>> >> at
>>> >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
>>> >> at
>>> >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
>>> >> at
>>> >>
>>> >>
>>>
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
>>> >> at java.lang.Thread.run(Unknown Source)
>>> >>
>>> >>
>>> >> Most awaiting for you reply
>>> >>
>>> >>
>>> >>
>>> >> Harry Metske wrote:
>>> >> >
>>> >> > Could you tell us a bit more about your configuration ?Are you
>>> running
>>> >> a
>>> >> > web
>>> >> > server in front of your container ?
>>> >> > Are you running Tomcat, could you share relevant entries in the
>>> access
>>> >> > logs
>>> >> > ?
>>> >> > Did you clean your browser cache ?
>>> >> > Try to run JSPWiki with a higher debug level (see bottom of
>>> >> > jspwiki.properties), maybe the jspwiki.log reveals something.
>>> >> > Could you share your jspwiki.properties with us, how do
>>> >> > your jspwiki.translatorReader.inlinePattern parameters look like
>>> ?
>>> >> >
>>> >> > /Harry
>>> >> >
>>> >> >
>>> >> > 2009/10/1 anilkumarkatta <anilkumarkatta@...>
>>> >> >
>>> >> >>
>>> >> >> Thanks again for your reply Janne.
>>> >> >>
>>> >> >> I tried with many number of times with changing the naming of the
>>> file
>>> >> >> including extention file type too..
>>> >> >>
>>> >> >> Its really a pinch for me that apart from .jpg file type..
>>> everything
>>> >> >> else
>>> >> >> working fine
>>> >> >>
>>> >> >> Please do advice me
>>> >> >>
>>> >> >> Thanks & Regards,
>>> >> >> -Anil Katta
>>> >> >>
>>> >> >> Janne Jalkanen wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> > You still get a 404 not found? Then it's very probably a case
>>> >> issue.
>>> >> >> > Try uploading a new image, and check if viewing that works. If
>>> it
>>> >> >> > does, then it's likely that your images are in different case
>>> than
>>> >> you
>>> >> >> > expect.
>>> >> >> >
>>> >> >> > For example, on Windows an image called "FOO.JPG" might actually
>>> >> turn
>>> >> >> > up as "foo.jpg", because Windows has some strange
>>> DOS-compatibility
>>> >> >> > rules.
>>> >> >> >
>>> >> >> > Please try to experiment with different images and name formats.
>>> >> >> > Please also check that the image *really* is in the repository
>>> and
>>> >> you
>>> >> >> > can open it up properly, and it's got correct permissions. 'cos
>>> if
>>> >> >> > downloading works for one kind of file, it should work on all
>>> kinds
>>> >> of
>>> >> >> > files, which makes me suspect it's a problem with the particular
>>> >> files
>>> >> >> > you're trying to access.
>>> >> >> >
>>> >> >> > /Janne
>>> >> >> >
>>> >> >> > On Sep 30, 2009, at 10:05 , anilkumarkatta wrote:
>>> >> >> >
>>> >> >> >>
>>> >> >> >> Hi
>>> >> >> >>
>>> >> >> >> Thanks for the Reply Janne.
>>> >> >> >>
>>> >> >> >> I took new copy of source code from the repository of the
>>> jspwiki,
>>> >> and
>>> >> >> >> modified. Attachment filter is working fine for all other
>>> >> >> >> attachements like
>>> >> >> >> GIF,PNG, zip, bmp, etc, but it not working with .jpg file type.
>>> >> >> >>
>>> >> >> >> Please your suggesstions are most welcomed.
>>> >> >> >>
>>> >> >> >> Thanks & Regards,
>>> >> >> >> -Anil Katta
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> Janne Jalkanen wrote:
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> Did you check that you have the correct web.xml file? And
>>> you're
>>> >> not
>>> >> >> >>> accidentally using the one from 2.0.x?
>>> >> >> >>>
>>> >> >> >>> /Janne
>>> >> >> >>>
>>> >> >> >>> On Sep 29, 2009, at 14:58 , anilkumarkatta wrote:
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>> further
>>> >> >> >>>>
>>> >> >> >>>> when I try opening the image files through attachement tab
>>> >> >> >>>>
>>> >> >> >>>> https://jspwiki.prodsup1.com/attach/Main/ACard.jpg
>>> >> >> >>>>
>>> >> >> >>>> it fetches me page not found
>>> >> >> >>>>
>>> >> >> >>>> Please hlep me
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>> anilkumarkatta wrote:
>>> >> >> >>>>>
>>> >> >> >>>>> Hi Todd
>>> >> >> >>>>>
>>> >> >> >>>>> Can you please give me what need to be done for this
>>> resolution
>>> >> of
>>> >> >> >>>>> the
>>> >> >> >>>>> issue.
>>> >> >> >>>>>
>>> >> >> >>>>> I am facing this issue since 2 months.
>>> >> >> >>>>>
>>> >> >> >>>>> you help would be much appreciated a lot
>>> >> >> >>>>>
>>> >> >> >>>>> Thanks & Regards,
>>> >> >> >>>>> - Anil Katta
>>> >> >> >>>>>
>>> >> >> >>>>>
>>> >> >> >>>>> Weis, Todd wrote:
>>> >> >> >>>>>>
>>> >> >> >>>>>> Duh... Forgot a backslash in directory name for
>>> attachments!
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> -----Original Message-----
>>> >> >> >>>>>>
>>> >> >> >>>>>> I recently upgraded from 2.05.52 to 2.8.1 and all my links
>>> for
>>> >> in-
>>> >> >> >>>>>> line
>>> >> >> >>>>>> attachments are broken. The files still exist, the system
>>> >> doesn't
>>> >> >> >>>>>> recognize it.
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> Page does not recognize it has a an attachment (doesn't show
>>> up
>>> >> on
>>> >> >> >>>>>> attach page).
>>> >> >> >>>>>>
>>> >> >> >>>>>> Inline images shows as broken x.
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> I did notice that the syntax has changed somewhat.
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> Old in line image
>>> >> >> >>>>>>
>>> >> >> >>>>>> [{Image src='james.jpg'
>>> >> link='attach?page=JamesPage%2Fjames.jpg'
>>> >> >> >>>>>> caption='James pic' alt='link to full size image' }]
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> New in line:
>>> >> >> >>>>>>
>>> >> >> >>>>>> [{Image src='james.jpg' link='attach/JamesPage/james.jpg'
>>> >> >> >>>>>> caption='James
>>> >> >> >>>>>> pic' alt='link to full size image' }]
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> I'm also not sure where it is storing the attachments in
>>> this
>>> >> new
>>> >> >> >>>>>> version.
>>> >> >> >>>>>>
>>> >> >> >>>>>> Old version had it in a attachment directory.
>>> >> >> >>>>>> (shared_storage\wiki\JamesPage-att\1.jpg)
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>> Any suggestions on how to fix?
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>>
>>> >> >> >>>>>
>>> >> >> >>>>>
>>> >> >> >>>>
>>> >> >> >>>> --
>>> >> >> >>>> View this message in context:
>>> >> >> >>>>
>>> >> >>
>>> >>
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25661728.html
>>> >> >> >>>> Sent from the JspWiki - User mailing list archive at
>>> Nabble.com.
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> View this message in context:
>>> >> >> >>
>>> >> >>
>>> >>
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25676020.html
>>> >> >> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >> --
>>> >> >> View this message in context:
>>> >> >>
>>> >>
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25692991.html
>>> >> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25746824.html
>>> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>>
>>> http://www.nabble.com/Upgrade-from-v2.0.52-to-v2.8.1-has-broken-attachments-tp25577952p25765357.html
>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>>
>
>
>