November 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Serialization] - Re: Poor performance with test...

by lxk123

The measure is taking against 1000 runs of cloning a same object, and the class loading should not be a big impact here. By the way, the smartClone method provided works great. On my test, it is more than twice as fast as the standard serialization. ------------- ByteArrayOutputStream bstream = new ByteArrayOutputStream(); org.jboss.serial.io.JBossObjectOutputStream out = new org.jboss.serial.io.JBossObjectOutputStream(bstream); Object newobj = out.smartClone(obj); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985027#3985027 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985027

19 years, 5 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: JDK1.6 retro compiler

by scott.stark＠jboss.org

Man, we barely have gotten to jdk5 support. Adding support for this in jbossretro is probably the minor issue. The bigger issue is not only having a jbossxxx project that requires both jdk5, and a jbossretro-rt6.jar. Another issue is how these future classes are being backported. Even with a java open source license, these classes cannot be merged into a jboss source tree. Is there an expanded backport project that covers both jdk5/6? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985023#3985023 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985023

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: FtpClientUtil refactoring

by kurt.stam＠jboss.com

Bruno, I think it makes sense to add a property to the PropertyManager configuration, which defines which implementation should be returned in the factory. All the other configuration should be added to the deployment-properties.xml, which I think is pretty much what you are going for. I can help you out with when it's integration time. Also by that time we need to refactor it to use the new Courier on the trunk. It supports setting up transports both ways (down and up). Take a look at the JmsCourier for instance. I think the FtpUploader and FtpDownloader fit right in there as an FtpCourier. But this is at a higher level then what you are working on right now, so let's not worry about that just yet. So basically I'm saying nothing but keep up the good work :). --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985021#3985021 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985021

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: onDemand handling and aspects

by scott.stark＠jboss.org

The current required configuration also seems a bit forced in that the one has to introduce the KernelControllerContextAware and then check for the install/unistall psuedo lifecycle methods. It seems like we need a more naturual place to define annotations that should apply to install/uninstall a bean into the kernel once all its dependencies are satified with a base class removes the need to check whether the method is an install or uninstall event. I have not drilled too far into what the mc hooks are available in this area as yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985019#3985019 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985019

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JSR-181 Annotation Based UDDI Registration

by anil.saldhana＠jboss.com

Kurt Stam from JBoss ESB has done an integrated juddi effort that basically calls juddi locally from the jaxr codebase. There has been no work done on this in jboss 4.0.x As outlined by jason, it is pretty simple to write a transport for juddi. That is what Kurt did. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985015#3985015 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985015

19 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Version Question

by clebert.suconic＠jboss.com

I haven't tried JDK 1.3.1 for a while. I have started it developing under 1.3, but I'm not sure if it would still work. I have used at least 1.4+. As for the XML, I'm uxing JMX properties not supported by JBoss 3.2.7. Maybe you could use the DLL on 3.2.7 (if you can switch the JVM to 1.4+).. and use kill -3 or Ctrl-Break to start/stop capturing data. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985011#3985011 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985011

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JSR-181 Annotation Based UDDI Registration

by jason.greene＠jboss.com

Looks like a local transport would be pretty simple to write. All that would be needed would be to abstract the code in JUDDIServlet (possibly into an MBean). And then reuses that module in the transport class. There is only one method to implement "send(Element)". http://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_0/varia/src/main... -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985010#3985010 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985010

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JSR-181 Annotation Based UDDI Registration

by jason.greene＠jboss.com

I don't think a local VM juddi transport exists yet, although Anil would know. Another alternative is to modify jUDDI directly, take a look at the main servlet that processes requests to see how. http://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_0/varia/src/main... -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985007#3985007 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985007

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JSR-181 Annotation Based UDDI Registration

by jgilbert

Hmmm... It is not practical to always deploy after the server has completely started. For example, what about when a server goes down and is restarted. So, it looks like the juddi server would need to be deployed in its own instance. Which is reasonable in a production environment. On a developer's machine it would be nice to avoid the extra process. The deployer could certainly be commented out. Any idea if jaxr supports a not-remote mode? Thanks for all the good feedback! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984995#3984995 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984995

19 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: LDAP Support expectations

by bdaw

Sorry for not responding for so long. | For now, can you please give me an understanding of the MembershipModule? | | - where is, e.g., getName() ? | - I can see: assignRoles(User user, Set roles) | does this mean, that all roles are only assigned to the user? | The whole idea of MembershipModule interface is to decouple Role and User. The reason is that in LDAP the relationship beetween them can be defined in several different ways - it's not so straight forward like in DB. So the main difference is NOT to have Role.getUsers() method. So Role and RoleModule know nothing about User and vice versa. And the functionallity is moved to MembershipModule to be able to resolve different ways of relationships just by swaping this module. I don't understand what .getName() method are you looking for there? anonymous wrote : | Let's imagine a "dynamic role assignment" feature with: | - assignRoles(Group group, Set roles), which adds roles to a group | - assignUser(Group group, Set users), which adds members to a group | | I was discussing your ideas with julien. There are few things in this subject: 1) Roadmap and features for 2.6 are already defined and we don't want to change them. The things you propose can be discussed to be placed in 3.0 roadmap - there is a plan to rethink and redesign this part already. Adding groups in the shape you descrived will need some changes in management portlets and other work so it's not an option at the moment. 2) Still, you can implement this functionality and we can integrate it in portal codebase as OPTIONAL. So simply it won't be enabled by default, but it can be used by changing portal configuration. If you agreed on this your code will need to meet few conditions: - it must be written in non intrusive way for what is in portal codebase. So it can't require changes to portal classes (or at least not much). - if you use DB your code can't breake the current schema. So you will probably need to add separate hibernate configuration with own tables - not a big effort as currently identity, portal objects and security schemas are also separated. I think it can be easily done. You can just add Group object and GroupModule that manage the relationship with User and Role. We can advise you how to plug into hibernate and etc in non intrusive way. 3) It may be possible to achive what you want just by providing implementation of LoginModule. Look at org.jboss.portal.identity.auth.IdentityLoginModule. It's portal implementation that plugs into JAAS in AS. So it could simply discover the group membership of the authenticating user and bind the relation with portal roles. How do you feal about it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984994#3984994 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984994

19 years, 5 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 November 2006