July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBREM-496) restructure service providers for remoting

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-496?page=comments#action_12339414 ] Tom Elrod commented on JBREM-496: ---------------------------------- org.jboss.remoting.transport.sslsocket - added. includes files that were under org.jboss.remoting.transport.socket.ssl org.jboss.remoting.transport.https- added. includes files that were under org.jboss.remoting.transport.http.ssl org.jboss.remoting.transport.sslmultiplex - added. includes files that were under org.jboss.remoting.transport.multiplex.ssl org.jboss.remoting.transport.sslrmi - added. includes files that were under org.jboss.remoting.transport.rmi.ssl > restructure service providers for remoting > ------------------------------------------ > > Key: JBREM-496 > URL: http://jira.jboss.com/jira/browse/JBREM-496 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.0.0.Beta2 (Boon) > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.0.0.CR1 (Boon) > > > Need a way to package and identify transport implementations for remoting. The idea is that anyone would be able to create their own transport implementation and drop it in and be "deployed" (where deployed means can just automatically discovered and used during runtime). > A few ideas of how to do this are: > 1. Use service provider from jar metadata - http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider > (e.g. URL[] urls = new Class().getResources("META-INF/services/org.jboss.remoting/Transport") ; ) > 2. Follow jndi pattern for package name. > (e.g. org.jboss.remoting.plugins.http.TransportFactory). -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-496) restructure service providers for remoting

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-496?page=comments#action_12339413 ] Tom Elrod commented on JBREM-496: ---------------------------------- No longer have InvokerRegistry: public static synchronized void registerInvoker(String transport, String clientClassName, String serverClassName) public static synchronized void registerInvoker(String transport, Class client, Class server) public static synchronized void unregisterInvoker(String transport) but instead have been replaced with: public static synchronized void registerInvokerFactories(String transport, Class clientFactory, Class serverFactory) public static synchronized void unregisterInvokerFactories(String transport) since invokers are created via factories now (for both client and server invokers) > restructure service providers for remoting > ------------------------------------------ > > Key: JBREM-496 > URL: http://jira.jboss.com/jira/browse/JBREM-496 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.0.0.Beta2 (Boon) > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.0.0.CR1 (Boon) > > > Need a way to package and identify transport implementations for remoting. The idea is that anyone would be able to create their own transport implementation and drop it in and be "deployed" (where deployed means can just automatically discovered and used during runtime). > A few ideas of how to do this are: > 1. Use service provider from jar metadata - http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider > (e.g. URL[] urls = new Class().getResources("META-INF/services/org.jboss.remoting/Transport") ; ) > 2. Follow jndi pattern for package name. > (e.g. org.jboss.remoting.plugins.http.TransportFactory). -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBREM-496) restructure service providers for remoting

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-496?page=all ] Tom Elrod resolved JBREM-496. ------------------------------ Resolution: Done > restructure service providers for remoting > ------------------------------------------ > > Key: JBREM-496 > URL: http://jira.jboss.com/jira/browse/JBREM-496 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.0.0.Beta2 (Boon) > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.0.0.CR1 (Boon) > > > Need a way to package and identify transport implementations for remoting. The idea is that anyone would be able to create their own transport implementation and drop it in and be "deployed" (where deployed means can just automatically discovered and used during runtime). > A few ideas of how to do this are: > 1. Use service provider from jar metadata - http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider > (e.g. URL[] urls = new Class().getResources("META-INF/services/org.jboss.remoting/Transport") ; ) > 2. Follow jndi pattern for package name. > (e.g. org.jboss.remoting.plugins.http.TransportFactory). -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-496) restructure service providers for remoting

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-496?page=comments#action_12339411 ] Tom Elrod commented on JBREM-496: ---------------------------------- Remoting will now load client and server invoker (transport) implementations within the InvokerRegistry using factories. The factory class to be loaded will always be either TransportClientFactory (for loading client invoker) or TransportServerFactory (for loading server invoker). These classes must implement org.jboss.remoting.transport.ClientFactory and org.jboss.remoting.transport.ServerFactory interfaces respectively. The package under which the TransportClientFactory and TransportServerFactory will always start with org.jboss.test.remoting.transport, then the transport protocol type. For example, the 'socket' transport factories can be found under org.jboss.remoting.transport.socket.TransportClientFactory and org.jboss.remoting.transport.socket.TransportServerFactory. The API for org.jboss.remoting.transport.ClientFactory is: public ClientInvoker createClientInvoker(InvokerLocator locator, Map config) throws IOException; public boolean supportsSSL(); The API for org.jboss.remoting.transport.ServerFactory is: public ServerInvoker createServerInvoker(InvokerLocator locator, Map config) throws IOException; public boolean supportsSSL(); An example of a transport client factory for the socket transport (org.jboss.remoting.transport.socket.TransportClientFactory) is: public class TransportClientFactory implements ClientFactory { public ClientInvoker createClientInvoker(InvokerLocator locator, Map config) throws IOException { return new SocketClientInvoker(locator, config); } public boolean supportsSSL() { return false; } } The packages used within the factory does not matter as long as they are on the classpath. Note that the transport factories are only loaded upon request for that protocol. Also, the client and server factories have been separated so that only the one requested is loaded (and thus the corresponding classes needed for that invoker implementation). So if only ask for a particular client transport invoker, only those classes are loaded and the ones needed for the server are not required to be on the classpath. > restructure service providers for remoting > ------------------------------------------ > > Key: JBREM-496 > URL: http://jira.jboss.com/jira/browse/JBREM-496 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.0.0.Beta2 (Boon) > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: 2.0.0.CR1 (Boon) > > > Need a way to package and identify transport implementations for remoting. The idea is that anyone would be able to create their own transport implementation and drop it in and be "deployed" (where deployed means can just automatically discovered and used during runtime). > A few ideas of how to do this are: > 1. Use service provider from jar metadata - http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider > (e.g. URL[] urls = new Class().getResources("META-INF/services/org.jboss.remoting/Transport") ; ) > 2. Follow jndi pattern for package name. > (e.g. org.jboss.remoting.plugins.http.TransportFactory). -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-492) would like an API to indicate if a transport requires SSL configuration

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-492?page=comments#action_12339410 ] Tom Elrod commented on JBREM-492: ---------------------------------- This has been changed to reside with the TransportClientFactory and TransportServerFactory, which extend ClientFactory and ServerFactory interfaces. The InvokerRegistry will then load the TransportClientFactory for the transport protocol specified and use that to determine if supports ssl. The call to the InvokerRegistry.isSSLSupported(String transport) remains the same. > would like an API to indicate if a transport requires SSL configuration > ----------------------------------------------------------------------- > > Key: JBREM-492 > URL: http://jira.jboss.com/jira/browse/JBREM-492 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Beta1 > Reporter: John Mazzitelli > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.0.0.CR1 (Boon) > > > Would like an API that I can use where I can give it a transport name (e.g. "http", "sslsocket", etc) and it returns true or false to indicate if its a secure transport and requires SSL configuration? Something like: > boolean isSecuredBySSL(String transport); > If you have a remoting app that is running outside of a JBossAS container (and thus don't have the pretty way to configure things with the [mbean] element), but still want to be able to change transports via a configuration file, it would be nice to be able to force a fail-fast configuration error if a secure transport was specified but no SSL configuration properties were specified (for example - if no keystore exists I'd want to fail fast, rather than wait to be told when the connector is started). If this API exists, this would be possible. > I flagged this with minor priority since you can kinda do this today via "if transport.startsWith("ssl") || transport.equals("https")" but that doesn't take into account any customized transports that are added to the registry during runtime nor does it take into account any new transports that might be added to the remoting core set of transports in the future. > InvokerRegistry looks like the class that would have this knowledge and would be where such an API lives, but it doesn't have it. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-368) Ternary expressions not allowed by the drl parser

by Michael Neale (JIRA)

Ternary expressions not allowed by the drl parser ------------------------------------------------- Key: JBRULES-368 URL: http://jira.jboss.com/jira/browse/JBRULES-368 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.2 Reporter: Michael Neale Assigned To: Michael Neale Fix For: 3.0.3 if (speed > speedLimit ? true : false;) pullEmOver(); The parser will have a warning over the "?" and then strip it out. -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-367) Can't use JANINO compiler

by Carlo Rossi (JIRA)

Can't use JANINO compiler ------------------------- Key: JBRULES-367 URL: http://jira.jboss.com/jira/browse/JBRULES-367 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.2 Reporter: Carlo Rossi Assigned To: Mark Proctor If I set the builder to use janino as compiler, using both enviroment variable -Ddrools.compiler=JANINO and programmatic configuration PackageBuilderConfiguration.setCompiler( PackageBuilderConfiguration.JANINO ), the compiler selected is always eclipse. I see in source that the switch that control the compiler to use is lacking of a break. -- 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, 6 months

2
2
0 / 0

[JBoss JIRA] Closed: (JBRULES-365) bug in fields inspection when creating Field Extractors for non-camelcase accessors

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-365?page=all ] Mark Proctor closed JBRULES-365. -------------------------------- > bug in fields inspection when creating Field Extractors for non-camelcase accessors > ----------------------------------------------------------------------------------- > > Key: JBRULES-365 > URL: http://jira.jboss.com/jira/browse/JBRULES-365 > Project: JBoss Rules > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Environment: Centrino, Gentoo Linux (Kernel 2.6.16), Eclipse 3.2 with JBoss Rules Plugin on Java 1.5.0_07 > Reporter: Andreas Langegger > Assigned To: Mark Proctor > Priority: Critical > Fix For: 3.1-m1, 3.0.3 > > > Consider a java bean or POJO with a public String FOO; and these accessors: > public String getFOO() { > return FOO; > } > public void setFOO(String foo) { > FOO = foo; > } > --------------------------------------- > The > rule "relation existance" > when > r : MyBean ( FOO == "" ) > then > System.out.println("Found " + r.getName() + "."); > end > ...will cause: > org.drools.rule.InvalidRulePackage: Unable to create Field Extractor for 'FOO' > at org.drools.rule.Package.checkValidity(Unknown Source) > at org.drools.common.AbstractRuleBase.addPackage(Unknown Source) > ... > Possible a quick fix only. > I've marked it BLOCKING, because it prevents me and possibly others of using Drools together with Jena, the Ontology API. > Best regards, > Andy -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBRULES-365) bug in fields inspection when creating Field Extractors for non-camelcase accessors

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-365?page=all ] Mark Proctor resolved JBRULES-365. ---------------------------------- Fix Version/s: 3.0.3 3.1-m1 Resolution: Done > bug in fields inspection when creating Field Extractors for non-camelcase accessors > ----------------------------------------------------------------------------------- > > Key: JBRULES-365 > URL: http://jira.jboss.com/jira/browse/JBRULES-365 > Project: JBoss Rules > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Environment: Centrino, Gentoo Linux (Kernel 2.6.16), Eclipse 3.2 with JBoss Rules Plugin on Java 1.5.0_07 > Reporter: Andreas Langegger > Assigned To: Mark Proctor > Priority: Critical > Fix For: 3.0.3, 3.1-m1 > > > Consider a java bean or POJO with a public String FOO; and these accessors: > public String getFOO() { > return FOO; > } > public void setFOO(String foo) { > FOO = foo; > } > --------------------------------------- > The > rule "relation existance" > when > r : MyBean ( FOO == "" ) > then > System.out.println("Found " + r.getName() + "."); > end > ...will cause: > org.drools.rule.InvalidRulePackage: Unable to create Field Extractor for 'FOO' > at org.drools.rule.Package.checkValidity(Unknown Source) > at org.drools.common.AbstractRuleBase.addPackage(Unknown Source) > ... > Possible a quick fix only. > I've marked it BLOCKING, because it prevents me and possibly others of using Drools together with Jena, the Ontology API. > Best regards, > Andy -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBRULES-365) bug in fields inspection when creating Field Extractors for non-camelcase accessors

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-365?page=comments#action_12339402 ] Mark Proctor commented on JBRULES-365: -------------------------------------- it turns out there is an Introspector standard for this - if the second char is a caps, then the first one is. So we now use Introspector.decapitalize(name);. This should align us with the javabean standard and solve y our problems :) > bug in fields inspection when creating Field Extractors for non-camelcase accessors > ----------------------------------------------------------------------------------- > > Key: JBRULES-365 > URL: http://jira.jboss.com/jira/browse/JBRULES-365 > Project: JBoss Rules > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Environment: Centrino, Gentoo Linux (Kernel 2.6.16), Eclipse 3.2 with JBoss Rules Plugin on Java 1.5.0_07 > Reporter: Andreas Langegger > Assigned To: Mark Proctor > Priority: Critical > > Consider a java bean or POJO with a public String FOO; and these accessors: > public String getFOO() { > return FOO; > } > public void setFOO(String foo) { > FOO = foo; > } > --------------------------------------- > The > rule "relation existance" > when > r : MyBean ( FOO == "" ) > then > System.out.println("Found " + r.getName() + "."); > end > ...will cause: > org.drools.rule.InvalidRulePackage: Unable to create Field Extractor for 'FOO' > at org.drools.rule.Package.checkValidity(Unknown Source) > at org.drools.common.AbstractRuleBase.addPackage(Unknown Source) > ... > Possible a quick fix only. > I've marked it BLOCKING, because it prevents me and possibly others of using Drools together with Jena, the Ontology API. > Best regards, > Andy -- 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, 6 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 July 2006