[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_12339353 ]
Mark Proctor commented on JBRULES-365:
--------------------------------------
I've chatted to michael on this. I'm going to revert the code and mark this as a "wont fix". seems he had already done the brain work on this. If you don't obey standard java naming conventions then you have to access the field via the full method name Ontclass( getURI == "....." ) - we won't support simple field names if if doesn't obey the java beans standard. Damn I should have left this code alone, anyway I think that still works now.
> 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
17 years, 9 months
- 1
- 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_12339350 ]
Mark Proctor commented on JBRULES-365:
--------------------------------------
After further thought this is harder than I imagined. When someone uses an Interface we have no way to know if the actual field is HTML or hTML when parsing hte getHTML method on the interface. suggestions?
> 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
17 years, 9 months
- 1
- 0
[JBoss JIRA] Updated: (EJBTHREE-617) Ability to configure the root context of a deployed ear.
by Torben Jaeger (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-617?page=all ]
Torben Jaeger updated EJBTHREE-617:
-----------------------------------
Attachment: ejbthree-617.patch
consolidated unit test
> Ability to configure the root context of a deployed ear.
> --------------------------------------------------------
>
> Key: EJBTHREE-617
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-617
> Project: EJB 3.0
> Issue Type: Feature Request
> Reporter: Adrian Pillinger
> Attachments: ejbthree-617.patch, ejbthree-617.patch
>
>
> Currently, if you deploy an ear named my-ear-1.2.1.ear, containing an EJB3 archive, which contains an EJB named MyBean it will deploy the remote interface to a JNDI name similar to:
> my-ear-1.2.1/MyBean/remote
> This can be nasty since client has to be updated each release to point to the correct JNDI name.
> To remedy this, a feature that allows configurability of the base portion of the JNDI name within the ear file, like the application.xml that provides the configuration of the root context for web apps.
> Basically, the functionality would allow the EJB to be configured to deploy to the following JNDI name, for examlpe
> my-ear/MyBean/remote
--
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, 9 months
- 1
- 0