August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Reopened: (JBAS-2904) Allow for ear modules to be deployed in the order that they are declared in application.xml

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2904?page=all ] Brian Stansberry reopened JBAS-2904: ------------------------------------ This change has introduced a testsuite failure when a datasource is packaged in an ear with an ejb jar. See JBAS-3503 for the failure. I'll comment on the forum thread with more details. > Allow for ear modules to be deployed in the order that they are declared in application.xml > ------------------------------------------------------------------------------------------- > > Key: JBAS-2904 > URL: http://jira.jboss.com/jira/browse/JBAS-2904 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8.SP1 > Reporter: Jim Moran > Assigned To: Vicky Kak > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1 > > -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-653) make the process parent classloader configurable

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-653?page=comments#action_12341027 ] Ronald van Kuijk commented on JBPM-653: --------------------------------------- Would this mean that if the jBPM engine is called from a servlet (either jsf or webservice) the web context classloader would be used? That would be great, then versioned classes in the process can have access to files in a war file... nice.. > make the process parent classloader configurable > ------------------------------------------------ > > Key: JBPM-653 > URL: http://jira.jboss.com/jira/browse/JBPM-653 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM 3.2 alpha 2 > > > now, always the jBPM classloader is taken as a parent for the process classloaders. this should be made configurable. at least one other possibility should be to configure the context classloader. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-217) unplugging of network cable makes jgroups behave weirdly

by David Forget (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-217?page=comments#action_12341026 ] David Forget commented on JGRP-217: ----------------------------------- This issue is only present on UDP when VIEW_SYNC is used. The workaround is then to remove VIEW_SYNC from the stack. > unplugging of network cable makes jgroups behave weirdly > -------------------------------------------------------- > > Key: JGRP-217 > URL: http://jira.jboss.com/jira/browse/JGRP-217 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.8, 2.2.9, 2.3 > Reporter: Manoranjan Sahu > Assigned To: Bela Ban > Fix For: 2.4 > > Attachments: logs.jar, mping.xml > > > Hi, > I am using jgroups 2.2.9 for communication in my cluster. > I was checking the behaviour of jgroups to network fluctuation. > for that I manually unplug the network cable and plug it back after some time. > But jgroups keeps sending suspected messages and never bring that into the cluster. > I have two machines in my cluster A(10.200.1.92) & B(10.200.1.74). > I unplug the cable in machine B. and plug it back . but B never joined the cluster. > Please find the attachment for the log files from both the machines. > I am using TCP based communication. I set up my protocol stack using . MPING,MERGE2,FD,VERIFY_SUSPECT,pbcast.NAKACK,pbcast.STABLE,VIEW_SYNC,pbcast.GMS. > The following are the confuguration in both the machines. > configuration setting in Machine-A > notificationbus.properties: > TCP(bind_addr=boca;recv_buf_size=200000;send_buf_size=100000;loopback=true; > start_port=7880): > MPING(timeout=4000;bind_to_all_interfaces=true;mcast_addr=228.8.8.8;mcast_port=7500; > ip_ttl=8;num_initial_members=4;num_ping_requests=1): > MERGE2(max_interval=10000;min_interval=5000): > FD(timeout=2000;max_tries=3): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(max_xmit_size=60000;gc_lag=50; > retransmit_timeout=100,200,300,600,1200,2400,4800): > pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;down_thread=false; > up_thread=false;max_bytes=0): > VIEW_SYNC(avg_send_interval=60000;down_thread=false;up_thread=false): > pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true) > ------------------------------- > configuration setting in Machine-B > notificationbus.properties: > TCP(bind_addr=rizal;recv_buf_size=200000;send_buf_size=100000; > loopback=true;start_port=7880): > MPING(timeout=4000;bind_to_all_interfaces=true;mcast_addr=228.8.8.8; > mcast_port=7500;ip_ttl=8;num_initial_members=4;num_ping_requests=1): > MERGE2(max_interval=10000;min_interval=5000):FD(timeout=2000;max_tries=3): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(max_xmit_size=60000;gc_lag=50; > retransmit_timeout=100,200,300,600,1200,2400,4800): > pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;down_thread=false; > up_thread=false;max_bytes=0): > VIEW_SYNC(avg_send_interval=60000;down_thread=false;up_thread=false): > pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true) > ---------------- -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-610) web service interface

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-610?page=comments#action_12341023 ] Ronald van Kuijk commented on JBPM-610: --------------------------------------- I think it shoud *not* be a facade for the SLSB, It should be able to run in plain tomcat as well. This is very doable as can be seen in JBPM717 and further. btw, what is the use of getProcessInstance. It is not in the command interface and al that is that is enhough. > web service interface > --------------------- > > Key: JBPM-610 > URL: http://jira.jboss.com/jira/browse/JBPM-610 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > > create a web service interface to the SLSB command based session facade -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBREM-419) Invokers Encryption

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-419?page=all ] Anil Saldhana reassigned JBREM-419: ----------------------------------- Assignee: Anil Saldhana (was: Tom Elrod) > Invokers Encryption > ------------------- > > Key: JBREM-419 > URL: http://jira.jboss.com/jira/browse/JBREM-419 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: transport, marshall, serialization > Reporter: Anil Saldhana > Assigned To: Anil Saldhana > Fix For: 2.2.0.Beta1 (Bluto) > > > I was thinking of a usecase where the user wanted to secure the channel but not use heavyweight ssl(and the dreaded certificate setup). > SealedObjects provide that flexibility of encrypting serializable objects. > http://java.sun.com/j2se/1.4.2/docs/api/javax/crypto/SealedObject.html -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-507) JDBCChannelMapper ignores CreateTablesOnStartup value from xxx-peristence-service.xml

by Ovidiu Feodorov (JIRA)

JDBCChannelMapper ignores CreateTablesOnStartup value from xxx-peristence-service.xml ------------------------------------------------------------------------------------- Key: JBMESSAGING-507 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-507 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Persistence Affects Versions: 1.0.1.CR4 Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 1.0.1.CR5 The value of JDBCChannelMapper's CreateTablesOnStartup attribute from xxx-peristence-service.xml does not propagate to the service, so JDBCChannelMapper will attempt to always create its tables. -- 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

19 years, 11 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBCACHE-656) Implement a Cachefactory for constructing a Cache

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-656?page=all ] Manik Surtani closed JBCACHE-656. --------------------------------- Resolution: Done > Implement a Cachefactory for constructing a Cache > ------------------------------------------------- > > Key: JBCACHE-656 > URL: http://jira.jboss.com/jira/browse/JBCACHE-656 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.SP2, 1.3.0, 1.3.0.SP1, 1.4.0 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Fix For: 2.0.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Simple cache factory to bring us closer to JSR107 -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-474) Compatibility fwk for all classes passed on the wire

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-474?page=all ] Manik Surtani updated JBCACHE-474: ---------------------------------- Fix Version/s: 2.1.0 (was: 2.0.0) > Compatibility fwk for all classes passed on the wire > ---------------------------------------------------- > > Key: JBCACHE-474 > URL: http://jira.jboss.com/jira/browse/JBCACHE-474 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4SP1 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Fix For: 2.1.0 > > > Classes that are serialized: > Fqn > MethodCall (JG?) > *Exception > GlobalTransaction > State transfers > 1) Lets use JGroups Streamable where possible (dependency? Externalizable instead?) > 2) Provide a header short containing version > 3) Use a MarshallingFactory for each version so we can understand messages from older installations > 4) Provide MarshallingFactories as plugins so old versions can talk to newer versions (fwd compat) > Object unmarshal(short version, Class type, InputStream is) > { > // if plugin directory empty or unset || version == currentVersion, revert back to existing mechanism > // else > // Look up UnmarshallerPlugin in the compat table (populated at startup with the contents of the plugin dir) > // Lookup based on version and class type. Unmarshaller then extracts and regenerates the relevant object. > } > Unit test as well. > Standalone fwk? jboss-compat.jar + plugins. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-67) JCache JSR-107 implementation

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-67?page=all ] Manik Surtani updated JBCACHE-67: --------------------------------- Fix Version/s: 2.1.0 (was: 2.0.0) > JCache JSR-107 implementation > ----------------------------- > > Key: JBCACHE-67 > URL: http://jira.jboss.com/jira/browse/JBCACHE-67 > Project: JBoss Cache > Issue Type: Feature Request > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.1.0 > > -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-728) add jump to function

by Tom Baeyens (JIRA)

add jump to function -------------------- Key: JBPM-728 URL: http://jira.jboss.com/jira/browse/JBPM-728 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens Whenever a user wants to jump to a given node, setNode might not be sufficient. Token.setNode only works properly if you're in a wait state. If during process execution you want to jump to a given node, you currently have to wait till the process enters a wait state and do the setNode then. This can impose side effects. One way of doing this is by means of throwing an exception. Maybe jbpm can use an exception internally to implement the jump... -- 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

19 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2006