[jira] Commented: (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577262#action_12577262
]
Paul Benedict commented on LANG-417:
If this necessitates a PackageUtils, then bump to 3.0.
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Paul Benedict
> Fix For: 2.4
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-38) ClassFunctions throws NPE searching for a function in null ns
[
https://issues.apache.org/jira/browse/JXPATH-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXPATH-38:
--
Summary: ClassFunctions throws NPE searching for a function in null ns
(was: [jxpath] ClassFunctions throws NPE searching for a function in null ns)
> ClassFunctions throws NPE searching for a function in null ns
> -
>
> Key: JXPATH-38
> URL: https://issues.apache.org/jira/browse/JXPATH-38
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.2 Final
> Environment: Operating System: other
> Platform: Other
>Reporter: Matt Benson
> Fix For: 1.3
>
> Attachments: jxpath-38.patch.txt
>
>
> First thing in getFunction(...):
> if (!namespace.equals(this.namespace)) {
> return null;
> }
> In contrast PackageFunctions has null checks. I think I can work around this
> by
> always using a namespace, but I can't think of any reason this behavior should
> persist into (theoretical) future versions of jxpath.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-50) does not properly handle NodeSet returned by extension function
[
https://issues.apache.org/jira/browse/JXPATH-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXPATH-50:
--
Summary: does not properly handle NodeSet returned by extension function
(was: [jxpath] does not properly handle NodeSet returned by extension function)
> does not properly handle NodeSet returned by extension function
> ---
>
> Key: JXPATH-50
> URL: https://issues.apache.org/jira/browse/JXPATH-50
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.2 Final
> Environment: Operating System: other
> Platform: All
>Reporter: Keith D Gregory
> Fix For: 1.3
>
> Attachments: jxpath-50.patch.txt, jxpath-nodeset-functions.patch
>
>
> Per the documentation, my function is returning a BasicNodeSet containing zero
> or more pointers:
> public static NodeSet observations(ExpressionContext context) {
> // the cast below shouldn't break, as this is the only pointer type that
> // makes sense in this context
> List ptrs = extractObservations(
>
> (NodePointer)context.getContextNodePointer(),
> new ArrayList());
> BasicNodeSet result = new BasicNodeSet();
> for (NodePointer ptr : ptrs) {
> result.add(ptr);
> }
> return result;
> }
> However, if I call JXPathContext.selectNodes("ems:observations()"), I'm
> getting
> a single node containing the BasicNodeSet. I notice that there is a testcase
> for
> functions that return NodeSets, but that it uses expressions that actually
> return the children of the NodeSet ("test:nodeSet()/name").
> There appear to be two problems. First, Expression.iterate() and
> Expression.iteratePointers() do not correctly recognize a NodeSet as something
> iterable. I've resolved this by reaching into the NodeSet and getting an
> iterator over its pointers.
> Second, Expression.PointerIterator doesn't recognize when it already has a
> pointer, and instead tries to wrap it in a new pointer. This ends up treating
> the pointer as a bean.
> I've made these changes, and written a testcase that uses an unadorned NodeSet
> function. I also found a class that used a variable named "enum", and changed
> this so that it would compile under 1.5.
> The patch is attached. It's relative to "commons-jxpath-1.2" (root of extract
> directory).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-46) NullPointerException
[ https://issues.apache.org/jira/browse/JXPATH-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated JXPATH-46: -- Summary: NullPointerException (was: [jxpath] NullPointerException) > NullPointerException > > > Key: JXPATH-46 > URL: https://issues.apache.org/jira/browse/JXPATH-46 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: 1.2 Final > Environment: Operating System: Linux > Platform: PC >Reporter: Chris Picton > Fix For: 1.3 > > Attachments: instance.xml, test.java > > > Using the following xpath, I get a NullPointerException, when trying to do a > getPointer(): > //[EMAIL PROTECTED]'1'][last()] > My code and instance data are attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-40) Problem in namespace handling
[ https://issues.apache.org/jira/browse/JXPATH-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated JXPATH-40: -- Summary: Problem in namespace handling (was: [JXPath] Problem in namespace handling) > Problem in namespace handling > - > > Key: JXPATH-40 > URL: https://issues.apache.org/jira/browse/JXPATH-40 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: 1.2 Final > Environment: Operating System: other > Platform: Other >Reporter: Gianugo Rabellino > Fix For: 1.3 > > Attachments: NotPropagatingRegisteredNSDeclarationsTest.java > > > The Cocoon forms framework relies heavily in JXPath for binding forms data to > business objects and/or XML. One of the newest requirements is being able to > use > XML namespaces as well, so we tried to integrate the latest JXPath version but > went through a blocker because of what seems to be a problem in namespace > inheritance. Attached is a test case which reproduces the issue, just drop to > src/test/org/apache/commons/jxpath and run the test suite (sorry for the messy > XML as an internal string, but it was the easiest way to send y'all some stuff > to test right away). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-37) JXPathException cause
[ https://issues.apache.org/jira/browse/JXPATH-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated JXPATH-37: -- Summary: JXPathException cause (was: [jxpath] JXPathException cause) > JXPathException cause > - > > Key: JXPATH-37 > URL: https://issues.apache.org/jira/browse/JXPATH-37 > Project: Commons JXPath > Issue Type: Bug > Environment: Operating System: All > Platform: All >Reporter: Vadim Gritsenko > Fix For: 1.3 > > Attachments: JXPathException.diff > > > Simple patch to JXPathException - guarantees better stacktraces under jdk > 1.4, > reduces developer's headaches (what is this InvocationTargetException???), > does > not harm anyone else. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-30) Source instructions on web site are wrong
[ https://issues.apache.org/jira/browse/JXPATH-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated JXPATH-30: -- Summary: Source instructions on web site are wrong (was: [jxpath] Source instructions on web site are wrong) > Source instructions on web site are wrong > - > > Key: JXPATH-30 > URL: https://issues.apache.org/jira/browse/JXPATH-30 > Project: Commons JXPath > Issue Type: Bug >Affects Versions: 1.2 Final > Environment: Operating System: All > Platform: All >Reporter: elharo > Fix For: 1.3 > > > The web site at http://jakarta.apache.org/commons/jxpath/ refers to the CVS > repository at least twice and links to the CVS repository. Apparently JXPath > has > switched to Subversion. The web site should be updated so it links to the > current SVN repository instead. This needs to be pushed out even in advance of > an actual release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-12) Descendant or self axis does not work correctly at root node
[
https://issues.apache.org/jira/browse/JXPATH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXPATH-12:
--
Summary: Descendant or self axis does not work correctly at root node
(was: [jxpath] Descendant or self axis does not work correctly at root node)
> Descendant or self axis does not work correctly at root node
>
>
> Key: JXPATH-12
> URL: https://issues.apache.org/jira/browse/JXPATH-12
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.2 Final
> Environment: Operating System: other
> Platform: Other
>Reporter: Simon Raess
> Fix For: 1.3
>
> Attachments: DescendantOrSelfTest.java, patch.jxpath-12.txt
>
>
> Given the following XML document:
> and the XPath: //root/@id/text().
> JXPath returns null instead of "1234".
> JXPathContext context = JXPathContext.newContext(doc);
> assertEquals(value, context.selectSingleNode("//root/@id/text()"));
> The attached JUnit test highlights the problem. It seems that JXPath does not
> find the root node if it is accessed with the axis descendant-or-self.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-5) asPath() returns a path to the last sibling
[
https://issues.apache.org/jira/browse/JXPATH-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXPATH-5:
-
Summary: asPath() returns a path to the last sibling (was: [jxpath]
asPath() returns a path to the last sibling)
> asPath() returns a path to the last sibling
> ---
>
> Key: JXPATH-5
> URL: https://issues.apache.org/jira/browse/JXPATH-5
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.2 Final
> Environment: Operating System: All
> Platform: All
>Reporter: Krishna Patil
> Fix For: 1.3
>
>
> The method call JXPathContext::iteratePointers() returns the correct number
> of
> pointers. However, the pointers do not always return correct path on asPath()
> method call on them. A pointer returns a path that corresponds to the last
> Node in the sibling Nodes of the node that the pointer points to.
> Here is an example:
> Class A{
>private List list;
> //getter and setter
> :
> }
> Here is a code snippet for creating an object graph that starts from
> instance of A.
> A a1 = new A();
> List list1 = new LinkedList();
> A a11 = new A();
> list1.add(a11);
> A a12 = new A();
> List list12 = new LinkedList();
> A a121 = new A();
> list12.add(a121);
> a12.setList(list12);
> list1.add(a12);
> A a13 = new A();
> list1.add(a11);
> a1.setList(list1);
> And the list attribute can have instances of A as elements in it.
> The JXPathContext correspong to a1 returns pointers when it's iteratePointers
> () method is called. And the pointers correspond to the following nodes.
> A[1]
> A[2]
> A[2]/A[1]
> A[3]
> This is absolutely as expected. However, asPath() method on each of these
> Pointers do not always return the correct path.
> Currently, the asPath() method calls on the corresponding Pointers return
> this
> output respectively.
> A[3]
> A[3]
> A[2]/A[1]
> A[3]
> This needs to be fixed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JXPATH-10) JXPath 1.1 code using custom functions failing when run in 1.2 onwards
[
https://issues.apache.org/jira/browse/JXPATH-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXPATH-10:
--
Summary: JXPath 1.1 code using custom functions failing when run in 1.2
onwards (was: [jxpath] JXPath 1.1 code using custom functions failing when run
in 1.2 onwards)
> JXPath 1.1 code using custom functions failing when run in 1.2 onwards
> --
>
> Key: JXPATH-10
> URL: https://issues.apache.org/jira/browse/JXPATH-10
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.2 Final
> Environment: Operating System: other
> Platform: PC
>Reporter: Paul Parisi
>Priority: Blocker
> Fix For: 1.3
>
>
> We have recently attempted to upgrade from a 1.1 release of jxpath
> to 1.2 and found a great deal of our jxpath code fails to run correctly.
> We isolated the problem to relating to the use of Custom Extension
> Functions and have included sample junit test case snippets that should
> demonstrate the issue clearly.
> The background on what we are trying to do with jxpath is as follows
> (included so its clear on what we are trying to use jxpath to achieve):
> Within our project, we make extensive use of Custom Extension Functions in
> JXPath.
> We also use JXPath variables significantly, in combination with these
> functions,
> that often take a JXPath variable as an argument(s) to the function.
> We now rely heavily on the use of the ExpressionContext interface as the
> first
> argument to many of our functions. The reason for this is that we need a
> convienient way to obtain access to 'original' object references within the
> context invoked by the function (as you would expect).
> However, we have also begun using a very useful combination of features, which
> the API supports in version 1.1, where the first argument always defines the
> ExpressionContext interface (which isn't really part of the method signature -
> from a caller perspective), and a 2nd argument as 'Object' type. Within body
> of
> the function, we then cast the object of the 2nd argument as a NodeSet (or
> define the NodeSet type within the method signature - either appears to work),
> which provides us with access to the pointers for the object.
> As previously mentioned, a jxpath variable is passed from the caller of the
> function (received via the 2nd argument in the method signature), which is
> automatically resolved, by jxpath, to the object itself.
> The benefit of casting the object to NodeSet (interface) enables us to
> retrieve
> the first pointer in the NodeSet list. The first pointer concerns us, as it
> refers to the String value passed to the argument of the function which we
> need
> access to. The object reference itself is of little concern in this case, as
> once we have access to the variable name sent to the function, we can access
> the
> object via the ExpressionContext.
> This all works fine in jxpath 1.1, however, in version 1.2 this functionality
> is
> now broken, since our objects are no longer being cast to NodeSet (previously
> achieved via the internal implementation of jxpath NodeSet using a
> SimpleNodeSet
> - as per inspecting jxpath 1.1 source code).
> Note on the use of ExpressionContext: For those methods that declare the
> ExpressionContext interface (which must be the first argument, if used), as
> part
> of the argument list, the method signature from the caller perspective,
> excludes
> it from the argument list, as it is implied by jxpath. In other words, there
> will be one less argument from the caller when the interface is used. In the
> case where this interface was the only argument, which is common, then the
> caller would be invoking a zero-argument method. This is behaviour we expect.
> Here is a simplified example of one of our functions using the techniques
> discussed:-
> public static void deleteSomeObject(ExpressionContext expContext, Object obj)
> {
> // create a local jxpath context to retrieve values for jxpath variables
> JXPathContext localContext = expContext.getJXPathContext();
> // Nodeset of the object passed to method
> NodeSet nodeset = (NodeSet)obj;
> // Retrieve variable name passed to function
> String declaredVariable = nodeset.getPointers().get(0).toString();
> Object objectToDelete = null;
> // If this method was passed the $obj1 var to delete, then retrieve 'Object
> Type
> 1' via $obj1 variable
>if (declaredVariable.equals("$obj1")) {
> objectToDelete = (ObjectType1)localContext.getValue("$obj1");
> }
> // If this method was passed the $obj2 var to delete, then retrieve
> 'Object
> Type 2' via $obj2 variable
> if (declaredVariable.equals("$obj2")) {
> objectToDelete = (ObjectType2)localCo
[jira] Updated: (JXPATH-2) Using JXPath in multiple threads
[
https://issues.apache.org/jira/browse/JXPATH-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated JXPATH-2:
-
Summary: Using JXPath in multiple threads (was: [jxpath] Using JXPath in
multiple threads)
> Using JXPath in multiple threads
>
>
> Key: JXPATH-2
> URL: https://issues.apache.org/jira/browse/JXPATH-2
> Project: Commons JXPath
> Issue Type: Bug
> Environment: Operating System: All
> Platform: All
>Reporter: Robert Sax
> Fix For: 1.3
>
>
> I was unable to determine if JXPath was intended to be used concurrently or
> not,
> but after using it in a server application that runs 100+ threads
> concurrently,
> I started getting errors (they were rare) that showed the following trace:
> java.lang.NullPointerException
> at
> org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getPropertyNames(BeanPropertyPointer.java:72)
> at
> org.apache.commons.jxpath.ri.model.beans.PropertyIterator.prepareForIndividualProperty(PropertyIterator.java:248)
> at
> org.apache.commons.jxpath.ri.model.beans.PropertyIterator.setPositionIndividualProperty(PropertyIterator.java:141)
> at
> org.apache.commons.jxpath.ri.model.beans.PropertyIterator.setPosition(PropertyIterator.java:127)
> at
> org.apache.commons.jxpath.ri.axes.ChildContext.setPosition(ChildContext.java:106)
> at
> org.apache.commons.jxpath.ri.axes.ChildContext.nextNode(ChildContext.java:89)
> at
> org.apache.commons.jxpath.ri.EvalContext.nextSet(EvalContext.java:322)
> at
> org.apache.commons.jxpath.ri.axes.UnionContext.setPosition(UnionContext.java:55)
> at
> org.apache.commons.jxpath.ri.axes.NodeSetContext.nextNode(NodeSetContext.java:64)
> at
> org.apache.commons.jxpath.ri.EvalContext.constructIterator(EvalContext.java:181)
> at
> org.apache.commons.jxpath.ri.EvalContext.hasNext(EvalContext.java:114)
> at
> com.paychex.hrs.ei.conversion.jaxb.InboundProcessor.process(InboundProcessor.java:136)
> The code calling has next looks like:
> Iterator oIter = m_oIdentifier.iteratePointers(oXCtx);
> >>>while (oIter.hasNext())
> {
> The application has 100 worker threads, each processing the same
> message(converted to beans by JAXB), but different instances of it. This error
> occurs infrequently - happening only about once every 3 runs (each run
> processes
> 1000 messages). I performed the test on a P4/Windows box, but I believe that
> this is independent of os/system.
> I believe I have found some of the source code that may be causing this. It
> appears that bean info is stored in an internal cache (JXPathIntrospector)
> that
> all threads would end up using. For this to be thread safe, JXPathIntrospector
> needs to be thread safe (which it is even though synchronization is not used),
> and JXPathBasicBeanInfo needs to be thread safe (it is not). Basically what is
> happening is that inside of JXPathBasicBeanInfo, a couple of procedures build
> member variables on demand. However this demand based building is not thread
> safe and so a race condition exists between multiple threads that are both
> performing the on demand building. Specifically getPropertyDescriptors and
> getPropertyDescriptor modify propertyDescriptors and propertyNames in an
> unsafe
> manner. Either synchronization should be used or the assignment to the member
> variable should be performed last (resulting in duplicate effort but thread
> safety). Here are the pieces of code I am referring to:
> public PropertyDescriptor[] getPropertyDescriptors() {
> if (propertyDescriptors == null) {
> try {
> BeanInfo bi = null;
> if (clazz.isInterface()) {
> bi = Introspector.getBeanInfo(clazz);
> }
> else {
> bi = Introspector.getBeanInfo(clazz, Object.class);
> }
> PropertyDescriptor[] pds = bi.getPropertyDescriptors();
> propertyDescriptors = new PropertyDescriptor[pds.length];
> // At this point, the cache of property descriptors has been cleared possibly
> // conflicting with other threads
> System.arraycopy(pds, 0, propertyDescriptors, 0, pds.length);
> Arrays.sort(propertyDescriptors, new Comparator() {
> public int compare(Object left, Object right) {
> return ((PropertyDescriptor)
> left).getName().compareTo(
> ((PropertyDescriptor) right).getName());
> }
> });
> }
> ...
> public PropertyDescriptor getPropertyDescriptor(String propertyName) {
> if (propertyNames == null) {
> PropertyDescriptor[] pds = getPropertyDescriptors();
>
[jira] Commented: (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577148#action_12577148
]
Matt Benson commented on LANG-417:
--
PackageUtils sounds reasonable from my POV; however, note that
java.lang.Package already exists and seems adequate for the purpose.
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Paul Benedict
> Fix For: 2.4
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577134#action_12577134
]
Robert Scholte commented on LANG-417:
-
Maybe this requires a PackageUtils, because it's got nothing to do with the
class itself but just with it's package.
I think the most logic method would be
public static String toResourcePath(Package p)...
public static String toResourcePath(Package p, String fqName) ...
this has to be combined with:
public static Package getPackage(Class clazz)
and yes, this would mean a new class: Package.
although it would require 2 steps, the methods would be very clear. IMHO the
suggested methodnames are just too ugly.
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Paul Benedict
> Fix For: 2.4
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SCXML-65) NullPointer exceptions during triggerEvent
[
https://issues.apache.org/jira/browse/SCXML-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577091#action_12577091
]
luc willems commented on SCXML-65:
--
hello Rahul,
i upgraded to current SVN source today , and all seems to be well now :-)
i'll be doing some more test on a sun T1000/solaris system this week.
luc
> NullPointer exceptions during triggerEvent
> --
>
> Key: SCXML-65
> URL: https://issues.apache.org/jira/browse/SCXML-65
> Project: Commons SCXML
> Issue Type: Bug
>Affects Versions: 0.7
> Environment: Linux opensuse 10.2 & Sun Solaris 10
> 1.5.x java
>Reporter: luc willems
> Fix For: 0.8
>
>
> i'm using SCXML state machines in a load generation tool. this tool simulates
> a client connected to a server.
> the SCXML script used custom actions to send a request using a HTTP based
> protocol.
> the HTTP response is transformed into a event and inserted into the SCXML
> script using triggerEvent().
> each SCML executor has 1 dedicated http connection. i'm using around 2 to
> 1 clients depending on the
> test scenario's.
> During execution of the scripts a get sporatic nullpointer exceptions. this
> DOESN'T happen all the time , it is hard to reproduce but when it happens ALL
> clients have the same problem. resetting the SCXML exector doesn't help
> 2008-01-24
> 14:33:35,593|scxml-1-88|ERROR|SCXMLUser.triggerEvents(181)|9|Current events:
> events(TriggerEvent{name=wv.status,type=3},TriggerEvent{name=wv.ok,type=3})
> 2008-01-24 14:33:35,594|scxml-1-88|ERROR|SCXMLUser.triggerEvents(182)|9|error
> scxml event trigger: null
> java.lang.NullPointerException
> at
> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.seedTargetSet(SCXMLSemanticsImpl.java:493)
> at
> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.followTransitions(SCXMLSemanticsImpl.java:652)
> at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:127)
> at com.nsn.loadtool.scxml.SCXMLUser.triggerEvents(SCXMLUser.java:164)
> at
> com.nsn.loadtool.scxml.SCXMLAsyncExecutor$SCXMLWorker.run(SCXMLAsyncExecutor.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595)
> all event triggering is done in a way that only 1 thread can trigger a event.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-187) TFTP Server for commons net
[ https://issues.apache.org/jira/browse/NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577090#action_12577090 ] Rory Winston commented on NET-187: -- Hi James Thanks! I was looking for a neat way to do this. I'll document this when it's done. Cheers Rory > TFTP Server for commons net > > > Key: NET-187 > URL: https://issues.apache.org/jira/browse/NET-187 > Project: Commons Net > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Dan Armbrust >Priority: Minor > Fix For: 2.0 > > Attachments: TFTPServer and Tests.patch > > > Bug for attaching TFTP Server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-187) TFTP Server for commons net
[ https://issues.apache.org/jira/browse/NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577082#action_12577082 ] James Carman commented on NET-187: -- Instead of having test classes in your distribution jar, I'd suggest you have Maven create a "test jar" for your project: http://maven.apache.org/guides/mini/guide-attached-tests.html This way, if someone wants to use your TFTPServer implementation, they can declare this dependency: org.apache.commons commons-net 2.0 *tests* > TFTP Server for commons net > > > Key: NET-187 > URL: https://issues.apache.org/jira/browse/NET-187 > Project: Commons Net > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Dan Armbrust >Priority: Minor > Fix For: 2.0 > > Attachments: TFTPServer and Tests.patch > > > Bug for attaching TFTP Server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-187) TFTP Server for commons net
[ https://issues.apache.org/jira/browse/NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577076#action_12577076 ] Rory Winston commented on NET-187: -- Hey Dan yes, i plan to release 2.0 and 1.5 simultaneously. It might be cleaner to keep the TFTP server in 2.0 for now. Cheers > TFTP Server for commons net > > > Key: NET-187 > URL: https://issues.apache.org/jira/browse/NET-187 > Project: Commons Net > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Dan Armbrust >Priority: Minor > Fix For: 2.0 > > Attachments: TFTPServer and Tests.patch > > > Bug for attaching TFTP Server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-187) TFTP Server for commons net
[ https://issues.apache.org/jira/browse/NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577042#action_12577042 ] Dan Armbrust commented on NET-187: -- As long as it is in the distribution jar, I'll be happy, since I won't have to keep my own copy on the side anymore. Did you want a fix for the jdk 1.2 issue - so it can go into the 1.5 build? Or is that process to far along already? Will you be releasing a 2.0 build along side the 1.5 build? I'm perfectly happy moving up to a 2.0 release if one is going to be available. > TFTP Server for commons net > > > Key: NET-187 > URL: https://issues.apache.org/jira/browse/NET-187 > Project: Commons Net > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Dan Armbrust >Priority: Minor > Fix For: 2.0 > > Attachments: TFTPServer and Tests.patch > > > Bug for attaching TFTP Server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
