February 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Fixing support for covariant return types.

by adrian＠jboss.org

Java5 introduced covariant return types but we weren't supporting this properly because MethodInfoImpl was taking into account the return type (and declaring class) when doing the equals check. I removed these two checks from the equals. Covariant return types are where you override the method to return a different type. e.g. | public class Something | { | public Object getSomething() {} ; | } | | public class StringSomething | { | // StringSomethings return a String not an Object | @Override | public String getSomething() {} ; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012025#4012025 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012025

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Descriptive element name a.k.a. label attribute

by koen.aers＠jboss.com

Hi Paolo, I created a JIRA issue for this (http://jira.jboss.com/jira/browse/GPD-54). It will be supported before GPD goes 3.1.0 GA. Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012022#4012022 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012022

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Failing tests

by adrian＠jboss.org

You need to move the tests to the container project as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012018#4012018 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012018

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - ProfileService.getRunningProfileName() ?

by charles.crouch＠jboss.com

So we need an api to return the name of the profile which is currently running on the server. In the current tests we just hardcode it to default: | InitialContext ctx = super.getInitialContext(); | ProfileService ps = (ProfileService) ctx.lookup("ProfileService"); | activeView = ps.getViewManager(); | ProfileKey defaultKey = new ProfileKey("default"); | activeView.loadProfile(defaultKey); What about: String ProfileService.getRunningProfileName() This would return "default", "all" depending upon how the server was started. In the future if you're accessing the ProfileService while the server was not running this would just return null. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012015#4012015 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012015

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: commands & EJB 3

by camunda

For the Authorization: My idea was much easier, just to have a, let's say | String[] getAllowedRoles | method in the Command. This returns the possible roles for the user. jBPM than can leave it up to the CommandService to do something with it, for example: - use JACC - use JAAS in the EJB-SessionBean - own implementation... With that you have it decoupled from the realization. Or what do you think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012007#4012007 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012007

19 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: DB test matrix

by prabhat.jha＠jboss.com

problem with wsrp and 4.0.4.GA is a known issue but it has not caused the build to fail in the past. The test log shows: deploy-producer-test: BUILD FAILED /home/cruisecontrol/work/checkout/jboss-portal-2.6-db/testsuite/build.xml:142: The following error occurred while executing this line: /home/cruisecontrol/work/checkout/jboss-portal-2.6-db/testsuite/build.xml:105: The following error occurred while executing this line: /home/cruisecontrol/work/checkout/jboss-portal-2.6-db/testsuite/build.xml:92: The following error occurred while executing this line: /home/cruisecontrol/work/checkout/jboss-portal-2.6-db/wsrp/build.xml:561: The following error occurred while executing this line: /home/cruisecontrol/work/checkout/jboss-portal-2.6-db/wsrp/build.xml:315: org.codehaus.cargo.container.ContainerException: Failed to deploy to [http://localhost:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=...] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012003#4012003 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012003

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: FYI: Latest ClassInfo changes.

by adrian＠jboss.org

"alesj" wrote : | Should I change get/set invocation in Actions as well? | Or slowly move all our pojo code to BeanInfo / PropertyInfo notion? The BeanInfo stuff (deliberately) doesn't understand the Property abstraction from the BeanMetaData so you still need an abstraction over the top of it to covert the property metadata to an Object. This is what is currently in the KernelConfigurator. Also in some places (like instantiation) there is the option to use a constructor or a factory. Only the constructor is supported by the BeanInfo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012002#4012002 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012002

19 years, 2 months

1
0
0 / 0

[Design of JBoss Build System] - New Maven Repositories

by pgier

I think it would be useful to have a separate snapshot repository for maven builds. We could set it up something like this: maven2/ - similar to our existing repository, but does not contain any snapshot builds. maven2-snapshots/ - contains snapshot versions One advantage of this is that we can configure the build to use a release profile that does not allow dependencies from the snapshots repository, so we can make sure that a release build only includes other releases. Also, the snapshot repository would not need to be in SVN or CVS, because each snapshot build will get a date and a build number attached to it. And it seems unlikely that we would need to regenerate an old snapshot. We could also be more open with the permissions in the snapshot repository so that developers can add jars as needed. The regular maven2 repository can be under stricter control updated only by release engineering. Another question is do we want to split the main repository from the plugins repository? Something like this: /maven2-plugin-releases/ /maven2-plugin-snapshots/ I don't see much advantage to this. It provides a little bit more organization, but I'm not sure if it's worth it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012000#4012000 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4012000

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: commands & EJB 3

by tom.baeyens＠jboss.com

"camunda" wrote : First of all: There is no EJB 3 SessionBean available, right? And because the Java 1.4 compability is still required we only can build a EJB 3 SessionBean in our own toolkit for jBPM, not the jbpm core, right? | no. you could include them into the jbpm sources. you just have to be very carefull not to introduce dependencies to java 5 in the current codebase. best way to do that is to make sure that the ejb3 part is in a separate source directory. probably in a separate sub project project. maybe an ejb3 subproject, right underneith the jbpm.3 root ? what do you think. if you can give that the same layout/build structure as the other subprojects (e.g. by starting from a copy of the enterprise project), you can just go ahead and try that. you can't do any harm by trying in a separate project ;-) "camunda" wrote : Also we use JAAS to autheticate users (to have different groups for deploying processes, signalling, cancelling, ...). We have annotated this in our EJB 3 Bean (e.g. @RolesAllowed( {"jbpm-admin-write"}) ). How can we do that with the commands? | with commands, you definitely cannot use the annotations based security. i think you could do it with JACC based authorization checks. i'll have to give that a second look if that would work out. "camunda" wrote : | One really generic and easy solution which came into my mind, is just to have the Command-Class-names as roles in JAAS (ok, not so nice for the administration) and then check, if the JAAS user is in the role in the SessionBean, so the JAAS-Logic is only in the SessionBean, nowhere else. | i think we should try to see of we can embed the JACC based authorization inside of the commands. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011999#4011999 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011999

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by clebert.suconic＠jboss.com

anonymous wrote : There are no strings involved. Ah... COREHEADERS is a BLOB. It's okay then... You convinced me :-) I understood we would create a new String field for these headers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011997#4011997 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011997

19 years, 2 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-dev-forums February 2007