July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1501) PortletTagHandler : not yet programmed in 2.6.0RC3

by Antoine Herzog (JIRA)

PortletTagHandler : not yet programmed in 2.6.0RC3 -------------------------------------------------- Key: JBPORTAL-1501 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1501 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6 CR3 Environment: JPB2.6.0 RC3 Reporter: Antoine Herzog Assigned To: Julien Viet The PortletTagHandler class is not yet programmed. The former code (for 2.4.1) is commented out. This class was patched for 2.4.2 and 2.4.6 See : http://jira.jboss.com/jira/browse/JBPORTAL-1316 It seems that the portlet rendering API has changed quiet a lot for 2.6 Any tips of what have changed : general philosophy of the change, where to find what have moved, etc... are welcome to help make a patch. I think this should be done for 2.6.0 final, has I know 2 portal in prod that use it yet (in 2.4.1). It is very usefull to put some portlets directly in the layout jsp framework, and not in "all the pages" : - chose the locale, - chose the theme (for special accessibility prestentation), - login and user portlet, - general main navigation, etc... Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1008) Subscription name escaping

by Sergey Koshcheyev (JIRA)

Subscription name escaping -------------------------- Key: JBMESSAGING-1008 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1008 Project: JBoss Messaging Issue Type: Feature Request Reporter: Sergey Koshcheyev Assigned To: Tim Fox Priority: Minor Fix For: 1.4.0.CR1 Need to escape/unescape subscription names so they can have dots in them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

1
2
0 / 0

[JBoss JIRA] Resolved: (JBRULES-40) RuleML export from Descr/AST

by Michael Neale (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-40?page=all ] Michael Neale resolved JBRULES-40. ---------------------------------- Resolution: Won't Fix > RuleML export from Descr/AST > ---------------------------- > > Key: JBRULES-40 > URL: http://jira.jboss.com/jira/browse/JBRULES-40 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Rule Assemply/SPI > Affects Versions: 3.0-beta1 > Reporter: Michael Neale > Assigned To: Michael Neale > Attachments: ruleml.zip > > > Need to be able to export out parsed rules as RuleML (a subset of correct RuleML). > RuleML->JBossRules can be achieved by XSLT (but could also use XML Binding to do similar more efficiently - possibly the same binding as exports). > RuleML (or whatever XML interchange format replaces it) will place some restrictions on the content of DRL (for instance, actions will only consist of functions etc). > This feature is often asked for as a requirement for adoption, as people like to have "insurance" that their rules are at least in part, portable. > (post 3.0 feature) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBPM-426) enable jpdl schema extension via namespaces

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-426?page=all ] Ronald van Kuijk reassigned JBPM-426: ------------------------------------- Assignee: Ronald van Kuijk (was: Tom Baeyens) > enable jpdl schema extension via namespaces > ------------------------------------------- > > Key: JBPM-426 > URL: http://jira.jboss.com/jira/browse/JBPM-426 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Affects Versions: jBPM 3.1, jBPM jPDL 3.2 > Reporter: Martin Dirichs > Assigned To: Ronald van Kuijk > Fix For: jBPM 3.3 > > > Customizing jpdl elements in a process definition via application-specific XML-elements is currently only possible outside of any schema validation. XML namespaces are the canonical way to allow for the extension of jpdl so that configuration data of delegation classes may be defined within an application-specific namespace and associated XML schema. In particular, this would be necessary to enable customization of jpdl elements > - action > - assignment > - handler > - controller > - task > Bug #JBPM-332: > http://jira.jboss.com/jira/browse/JBPM-332 > is somewhat related to this issue. However, resolution of JBPM-332 > - only allows for arbitrary elements to appear inside jpdl files (without schema validation) > - and only for customizing assignments (leaving out action, handler, controller and task). > Implementation of this feature request would be done via a more intelligent version of an EntityResolver (defined in org.jbpm.jpdl.xml.SchemaValidationHandle) that can return application specific schemas in addition to the default one for jpdl. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-964) drl header can contain garbage - no errors reported (but parsing fails)

by Michael Neale (JIRA)

drl header can contain garbage - no errors reported (but parsing fails) ----------------------------------------------------------------------- Key: JBRULES-964 URL: http://jira.jboss.com/jira/browse/JBRULES-964 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.MR3 Environment: Take a look at RuleParserTest - FIXME_testPackageGarbage - it will show a drl that does not report errors that should (came across this when experimenting with dialect - I accidentally put it after the imports). Reporter: Michael Neale Assigned To: Edson Tirelli Priority: Critical -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-960) WorkingMemory cannot insert proxy object

by zhou yanming (JIRA)

WorkingMemory cannot insert proxy object ---------------------------------------- Key: JBRULES-960 URL: http://jira.jboss.com/jira/browse/JBRULES-960 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.MR3 Reporter: zhou yanming Assigned To: Mark Proctor Priority: Critical Fix For: 4.0.0.MR4 object was proxied by CGLIB,and works fine with 4.0.0.MR2,but when I upgrade to 4.0.0.MR3,It raise a exception Caused by: java.lang.VerifyError: model.Order$$EnhancerByCGLIB$$d6d596a8ShadowProxy overrides final method ?0ó*h=+.?0ó*h=+ at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.lang.ClassLoader.defineClass(ClassLoader.java:465) at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:40) at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:59) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.drools.reteoo.Rete$ObjectTypeConf.<init>(Rete.java:352) at org.drools.reteoo.Rete.assertObject(Rete.java:152) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:584) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (JGRP-503) Retransmitted message too large

by Bela Ban (JIRA)

Retransmitted message too large ------------------------------- Key: JGRP-503 URL: http://jira.jboss.com/jira/browse/JGRP-503 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=4288472 By: whatagreatuser After leaving a 3 member cluster running for ~2 hours, received bunches of errors on all the members. Below is the config XML, which is basically udp.xml with some tweaks for for larger thread_pool and oob_thread_pool. The Channel is basically used as an RPC layer with an RpcDispatcher sitting on top of it. At the time of the errors no â€œuser-levelâ€ messages were being sent. No state is being managed by the channel either. //channel setup channel=new JChannel(jgroups_config_file); channel.setOpt(Channel.AUTO_RECONNECT, Boolean.TRUE); channel.addChannelListener(this); disp=new RpcDispatcher(channel, null, this, this, true, true); //force connect channel.connect(clusterName); ERROR | failed sending message to 10.0.0.64:28701 (163 bytes) java.lang.Exception: dest=/10.0.0.64:28701 (65508 bytes) at org.jgroups.protocols.UDP._send(UDP.java:345) at org.jgroups.protocols.UDP.sendToSingleMember(UDP.java:302) at org.jgroups.protocols.TP.doSend(TP.java:1197) at org.jgroups.protocols.TP.send(TP.java:1184) at org.jgroups.protocols.TP.down(TP.java:957) at org.jgroups.protocols.Discovery.down(Discovery.java:325) at org.jgroups.protocols.MERGE2.down(MERGE2.java:184) at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:406) at org.jgroups.protocols.FD.down(FD.java:363) at org.jgroups.stack.Protocol.down(Protocol.java:270) at org.jgroups.protocols.BARRIER.down(BARRIER.java:94) at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:494) at org.jgroups.protocols.UNICAST.retransmit(UNICAST.java:467) at org.jgroups.stack.AckSenderWindow.retransmit(AckSenderWindow.java:145) at org.jgroups.stack.Retransmitter$Entry.run(Retransmitter.java:339) at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:187) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:65) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168) 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) Caused by: java.net.SocketException: The message is larger than the maximum supported by the underlying transport: Datagram send failed at java.net.PlainDatagramSocketImpl.send(Native Method) at java.net.DatagramSocket.send(DatagramSocket.java:612) at org.jgroups.protocols.UDP._send(UDP.java:341) ... 23 more ERROR | failed sending message to 10.0.0.64:28701 (163 bytes) java.lang.Exception: dest=/10.0.0.64:28701 (65508 bytes) at org.jgroups.protocols.UDP._send(UDP.java:345) at org.jgroups.protocols.UDP.sendToSingleMember(UDP.java:302) at org.jgroups.protocols.TP.doSend(TP.java:1197) at org.jgroups.protocols.TP.send(TP.java:1184) at org.jgroups.protocols.TP.down(TP.java:957) at org.jgroups.protocols.Discovery.down(Discovery.java:325) at org.jgroups.protocols.MERGE2.down(MERGE2.java:184) at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:406) at org.jgroups.protocols.FD.down(FD.java:363) at org.jgroups.stack.Protocol.down(Protocol.java:270) at org.jgroups.protocols.BARRIER.down(BARRIER.java:94) at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:494) at org.jgroups.protocols.UNICAST.retransmit(UNICAST.java:467) at org.jgroups.stack.AckSenderWindow.retransmit(AckSenderWindow.java :145) at org.jgroups.stack.Retransmitter$Entry.run(Retransmitter.java:339) at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java :187) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.jav a:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269 ) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureT ask.access$301(ScheduledThreadPoolExecutor.java:65) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureT ask.run(ScheduledThreadPoolExecutor.java:168) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPool Executor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec utor.java:675) at java.lang.Thread.run(Thread.java:595) Caused by: java.net.SocketException: The message is larger than the maximum supported by the underlying transport: Datagram send failed at java.net.PlainDatagramSocketImpl.send(Native Method) at java.net.DatagramSocket.send(DatagramSocket.java:612) at org.jgroups.protocols.UDP._send(UDP.java:341) ... 23 more ERROR | failed sending message to 10.0.0.64:28702 (66863 bytes) java.lang.Exception: message size (66935) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly at org.jgroups.protocols.TP$Bundler.checkLength(TP.java:1781) at org.jgroups.protocols.TP$Bundler.send(TP.java:1670) at org.jgroups.protocols.TP$Bundler.access$100(TP.java:1657) at org.jgroups.protocols.TP.send(TP.java:1173) at org.jgroups.protocols.TP.down(TP.java:957) at org.jgroups.protocols.Discovery.down(Discovery.java:325) at org.jgroups.protocols.MERGE2.down(MERGE2.java:184) at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:406) at org.jgroups.protocols.FD.down(FD.java:363) at org.jgroups.stack.Protocol.down(Protocol.java:270) at org.jgroups.protocols.BARRIER.down(BARRIER.java:94) at org.jgroups.protocols.pbcast.NAKACK.sendXmitRsp(NAKACK.java:840) at org.jgroups.protocols.pbcast.NAKACK.handleXmitReq(NAKACK.java:789 ) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:537) at org.jgroups.protocols.BARRIER.up(BARRIER.java:119) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:154) at org.jgroups.protocols.FD.up(FD.java:328) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301) at org.jgroups.protocols.MERGE2.up(MERGE2.java:145) at org.jgroups.protocols.Discovery.up(Discovery.java:224) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1 541) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1495) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPool Executor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec utor.java:675) at java.lang.Thread.run(Thread.java:595)  <config> <UDP mcast_addr="${jgroups.udp.mcast_addr:228.10.10.50}" mcast_port="${jgroups.udp.mcast_port:50000}" tos="8" ucast_recv_buf_size="20000000" ucast_send_buf_size="640000" mcast_recv_buf_size="25000000" mcast_send_buf_size="640000" loopback="false" discard_incompatible_packets="true" max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="true" ip_ttl="${jgroups.udp.ip_ttl:2}" enable_bundling="true" enable_diagnostics="true" thread_naming_pattern="cl" use_concurrent_stack="true" thread_pool.enabled="true" thread_pool.min_threads="1" thread_pool.max_threads="250" thread_pool.keep_alive_time="60000" thread_pool.queue_enabled="true" thread_pool.queue_max_size="10000" thread_pool.rejection_policy="Abort" oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1" oob_thread_pool.max_threads="250" oob_thread_pool.keep_alive_time="60000" oob_thread_pool.queue_enabled="true" oob_thread_pool.queue_max_size="10000" oob_thread_pool.rejection_policy="Abort"/> <PING timeout="2000" num_initial_members="2"/> <MERGE2 max_interval="30000" min_interval="10000"/> <FD_SOCK/> <FD timeout="10000" max_tries="5" shun="true"/> <VERIFY_SUSPECT timeout="1500" /> <BARRIER /> <pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="true"/> <UNICAST timeout="300,600,1200,2400,3600"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/> <VIEW_SYNC avg_send_interval="60000" /> <pbcast.GMS print_local_addr="true" join_timeout="3000" join_retry_timeout="2000" shun="false" view_bundling="true"/> <FC max_credits="20000000" min_threshold="0.10"/> <FRAG2 frag_size="60000" />  <pbcast.STATE_TRANSFER />  </config> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

2
5
0 / 0

[JBoss JIRA] Closed: (JBMICROCONT-11) Extend the VDF BasicComponent to handle http and/or webdav

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-11?page=all ] Adrian Brock closed JBMICROCONT-11. ----------------------------------- Fix Version/s: (was: JBossMC-2.2.0.GA) Resolution: Out of Date > Extend the VDF BasicComponent to handle http and/or webdav > ---------------------------------------------------------- > > Key: JBMICROCONT-11 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-11 > Project: JBoss MicroContainer > Issue Type: Feature Request > Components: Deployment > Environment: org.jboss.deployment.vdf.plugins.basic > Reporter: Dimitris Andreadis > > Currently it handles locals files/directories (file:/...../xx) so it should be extended to handle remote urls, including webdav enabled ones. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBMICROCONT-78) Rework the JMX Decorator for "on-demand"

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-78?page=all ] Adrian Brock reassigned JBMICROCONT-78: --------------------------------------- Assignee: Adrian Brock > Rework the JMX Decorator for "on-demand" > ---------------------------------------- > > Key: JBMICROCONT-78 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-78 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossMC_2_0_0_CR1 > > > The JMX Decorator needs reworking such that it can act > as a "hollow" proxy before the instance exists. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBMICROCONT-79) Extend the JMX Decorator such that can expose a JSR77 contract

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-79?page=all ] Adrian Brock reassigned JBMICROCONT-79: --------------------------------------- Assignee: Adrian Brock > Extend the JMX Decorator such that can expose a JSR77 contract > -------------------------------------------------------------- > > Key: JBMICROCONT-79 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-79 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: General > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossMC_2_0_0_CR1 > > > The JMX Decorator needs to act in co-operation with the profile service and > metadata repository "scope" such it can expose a jsr77 view that > 1) use the "scope" to define the instance's location in the jsr77 "tree" > 2) provides the jsr77 lifecycle view > 3) can "consolidate" the statistics into the jsr77 view for this instance > 4) the profile service understands the "scope" such it can retrieve the jsr77 view of the instance, > deployment, application > "jsr77" is used here in a loose sense. The real jsr77 can built on top this processing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007