nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

java.lang.ClassCastException: com.interwoven.dc100

System

What does this (in servletd.log) mean when saving a DCR (the UI shows "Saving" but it never saves):

2004-06-03 10:20:29 - Ctx( /iw/webdesk ): Exception in: R( /iw/webdesk + /templating/DatacaptureServlet + null) - java.lang.ClassCastException: com.interwoven.dc100.core.TAndContainer
at com.interwoven.templating.DCRDocumentManipulator.setValues(DCRDocumentManipulator.java:80)
at com.interwoven.templating.DatacaptureServlet.doSaveDCR(DatacaptureServlet.java:1587)
at com.interwoven.templating.DatacaptureServlet.doGet(DatacaptureServlet.java:132)
at com.interwoven.templating.DatacaptureServlet.doPost(DatacaptureServlet.java:176)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at com.interwoven.framework.base.FrameworkServlet.service(FrameworkServlet.java:66)
at com.interwoven.framework.auth.AuthServlet.service(AuthServlet.java:96)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service(Handler.java:287)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:213)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:423)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
at java.lang.Thread.run(Thread.java:484)

Find more posts tagged with

Comments

Sri

Hi,

The error is most likely caused by some structural inconsistencies in the datacapture.cfg. If possible, please post the datacapture.cfg.

Sri

Migrateduser

There was a cut-and-pasto in the DCT, there was a container with the same name as an item at the same level. This kind of thing should throw an error at DCT parse time (before presenting the UI) rather than after data is entered, and instead of a java stack trace in some forgotten log it should throw an error in the UI.

Sri

I agree. It should be more obvious that DCT is invalid. Can you file a bug report against 5.5.x?

In 6.x, there is a dct validator CLT that can be used to validate a DCT and I believe an error is thrown in the UI beofre the form is opened.

Migrateduser

I can't really file bugs as I'm not a real customer - in fact my next project starts Monday. I also think there should be a tool to validate that a DCR conforms to the rules described by a DCT.

Sri

I can't really file bugs as I'm not a real customer - in fact my next project starts Monday.
You can ask your customer to file a bug for you. :-)

I also think there should be a tool to validate that a DCR conforms to the rules described by a DCT.
If the DCR is a pure XML that conforms to a customer specified DTD, then there is no need to have a special validation tool as it can be validated with iwxml_validate.ipl or any generic XML validator tool.

Are you talking about DCRs that are of IWOV style? ie DCRs that have item/value tags and do not conform to a customer specified DTD. I was just wondering the use case for such a tool for IWOV dcrs. Is it that in your case, iwov styles DCRs are created through automated scripts rather than through UI?

Thanks
Sri

Migrateduser

On this project content is being migrated from a legacy system into Interwoven-style DCRs. This is done with Perl scripts, Java, XSL, etc. When the records are created it would be nice to validate them before giving them to the users to validate (it appears that the only way to validate is to open them in the UI, which is kinda ridiculous). Also if a DCT changes we need to scrub the DCRs; validation would be nice at that point as well. Can't believe I'm the first "user" to raise this one...

Migrateduser

> You can ask your customer to file a bug for you. :-)

I am not sure there is much point - the bugs I have filed in the past have not been fixed and the requested features have not been added, so I have developed workarounds. Since the workarounds work I don't think the client will later refactor the code to use the IW-provided functionality. If the feature is added or bug fixed, Interwoven would contact the customer, who probably doesn't know or care about the bug, rather than contacting me who does know and care. So it just adds cycles, especially when Interwoven does not fix the bug or add the feature.

It seems illogical that you would have to be a customer to file a bug, but I guess it keeps the bug stats down (since contractors and consultants are much more likely to find bugs in the product than customers are).

Adam Stoller

I file bugs and feature requests as a consultant all the time.
First - you get the customer to add you as one of the people who can access the support site for them
Second - when you file the request - explicitly ask for correspondence to be sent to your email address (if it's different than the address used for your support site access account).
Third - While it would be great if interwoven could fix *every* bug and implement *every* feature request - it's unreasonable to really expect that. Things generally come down to the old 80/20 rule *and* having as many customers associated with issues as possible to make it clear that they fit into the 80/20 rule.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

What percentage of your bugs/features would you guess have been addressed? 80, 20 or other?

nipper

> What percentage of your bugs/features would you guess have been addressed? 80, 20 or other?

Can't wait for Smitty to answer that.

10-20 % for me, no rhyme or reason to what gets addressed except who screams loudest.

Migrateduser

Though I've filed dozens of bugs and feature requests, to my knowledge the only one they've addressed was on 4.5 for NT4. The machine would bluescreen if iwupdate was called under certain conditions so I think they pretty much had to fix that one, and before they did we had to file support cases with Microsoft (the OS vendor), IBM (the hardware vendor) and they wanted us to file with Intel (they apparently make some kind of hardware) and 3com (they make nics), even though the stopcode was clearly an Interwoven stopcode. So I would say my percentage is below 5 and that one took months (in which time we rewrote all workflows to not call iwupdate), which makes it not worth my while to file bugs.

Edited by JimmyFat on 06/04/04 01:40 PM (server time).

Migrateduser

Things generally come down to the old 80/20 rule *and* having as many customers associated with issues as possible to make it clear that they fit into the 80/20 rule.

Glad you pointed this out, as it has been pointed out by many Interwoven representatives time and time again. The practice of fixing the bugs and features that more customers attached themselves to would make a lot of sense....if only all the customers could see all the bugs and requested features that exist. Until Interwoven shares the bug and feature request list, this practice could not be more flawed. It is unfair and irresponsible to claim that's how bugs fall on the priority list when the list is hidden. I might be interested in tens of thousands of open bugs if I only knew what they were. You might claim there aren't tens of thousands of open bugs, but then I would just ask you how you would know since you aren't privy to the list now that you don't work there. This also runs smack into the kinds of claims Interwoven likes to make about why they do certain things using terms like "most customers wanted this" and "the majority of customers didn't want that". When you ask anyone at Interwoven what percentage of customers were queried on those occasions and which ones were chosen to participate and which weren't, you get a deafening amount of silence in response. It's all BS as far as I'm concerned.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

Trust me, screaming the loudest doesn't help much either.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

>Trust me, screaming the loudest doesn't help much either.

Hmmm, we must scream louder than you. We have actually had a bug with a special patch
(and I know it was not something other companies looked at) that IW rolled into an SP. It would
have stopped a 200 person project deployment & there was some seriously loud screaming.

Andy

nipper

>if only all the customers could see all the bugs and requested features that exist.

No question this is the most **** backwards system I have ever seen. I am certain there are
bugs and feature requests that other companies have seen & we would like resolved. Most
of the time you learn to live with or work around them & don't bother logging a bug. So
the contention that IW is fixing the most requested bugs/FRs is dubious at best.

Kind of like the iPod drawing.

no I am not bitter <GR!!!!>

Andy

lhdavis

Can we make a feature request to open up the bug and feature request list on DevNet?

In all seriousness, it would really make life easier on Interwoven customers and their associated developers if we could see the bug and feature request list and attach our customer to the desired ones. And I appreciate the DevNet posters who share their feature request numbers on the site so we can do that...but Interwoven should be providing that information to us if their justification for adding some features but forgoing others is the number of customers who requested it.

Maybe post the numbers for how many customers wanted certain things (hopefully we wouldn't get any American Idol-style controversy with the voting results)

I mean, come on, it's not like it's the Holy Grail or anything...we know it exists so show it to us.

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

Migrateduser

This has come up before, it would certainly make life easier if we could see the bugs, but this forum is so open that they can't expose them here (competition getting bug stats, seeing how few get resolved and how long it takes, etc. would be a bad thing for iw).

lhdavis

Then add it to the official support site which is more secure.

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

Migrateduser

I do recall at either the last Focus Group or the one before that (It's been so long since there was a Focus Group it's hard to remember now) that there was some hope of Interwoven opening up at least the bug list, but I don't think they wanted to open up the feature request list. I don't remember why exactly, but they claimed it was really hard to do for some reason. How hard is it to keep a friggin' list up to date? Maybe it was a matter of how much time it would take to maintain or type in all the details or some such nonsense. Now that there are no Focus Groups there isn't a central place to **** to all the key players about it, so they can just come back and claim that most customers don't want the bug and feature request list exposed and who can argue with that?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

lhdavis

- who can argue with that?

Um, you? Smiley Happy

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

Migrateduser

It belongs on the support site, not on DevNet.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

See but I don't have access to the support site either. I do request support access when I join a project but they don't always grant it.

nipper

>It belongs on the support site, not on DevNet.

Let's hope KevinC decides to join this converstion. Maybe one of the IW lurkers will
suggest he through his 2 c in.

& it does belong on support not devnet.

Andy

Migrateduser

Well therein lies a dilemma for consultants. However, the concept that customers determine which bugs/features to implement would be met by utilizing the support site, which is accessible by all customers, who may choose to give their consultants access if they so desire, I think. It would be hard to give consultants access to the support site directly since they can always go off and work at a competitor unbeknownst to Interwoven - your whereabouts can never really be known, you sneaky little consultant bastards, you. Smiley Happy

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com