[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by alesj
"david.lloyd(a)jboss.com" wrote :
| Far simpler than designing a plugin mechanism for restrictions is to simplify the API so that you just give it the input streams of classes you want to index. Simplfying the API is usually preferable to adding an abstraction.
|
A? What kind of nonsense is this?
And how do you plan on providing this streams?
Via abstraction!!!!
Or how else are you gonna know which one's should or shouldn't be scanned?
Should I list them by hand, all of the 1M classes?
Or what about if tomorrow Sun speeds up its modules impl,
and we all start doing module-info.java?
"david.lloyd(a)jboss.com" wrote :
| The specifications for many of our components (like EJB 3.1) tell us that we can't rely on this, or at least that's my understanding from the developer meeting when we decided we had to do it this way.
Then I would say this is their problem.
Who ever doesn't have automated build, has either just started programming or is moro....
The first one's don't need this feature yet, the 2nd one's don't deserve it. ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261322#4261322
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261322
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by alesj
"david.lloyd(a)jboss.com" wrote :
| Wrong. Because you end up contorting your code to match the use-case of the dependency, rather than the use case you're trying to achieve, causing ineffective code to become further entrenched, and making it even harder to fix later.
|
A?
What's the point of frameworks then?
In my case all of the used libs were a perfect fit.
Dunno what kind of crap you use. ;-)
"david.lloyd(a)jboss.com" wrote :
| Many projects relied on VFS because it is written for a particular use case.
|
What particular use case?
Current VFS does exactly what it was meant for or what you expect from vfs.
The API is simple and usable, features are pretty rich.
Where we might argue about impl details,
the overall goals were achieved:
* single point of controlling resources lookup
** handling file locking
** file vs. jar vs. dir abstraction
** visitor pattern
* extension points
** assembled
** in-memory
* ...
But well, now that I see your take on ext libs,
I'm no longer wondering why VFS3, vs. trying to fix existing impl.
"david.lloyd(a)jboss.com" wrote :
| However, it just happened to be completely wrong. Now fixing it is a huge undertaking.
|
Wrong in what way?
Going back to AS4 behind an VFS api (aka VFS3) doesn't make it right. ;-)
"david.lloyd(a)jboss.com" wrote :
| Refactoring code is easy. Refactoring semantics is really difficult (see VFS again).
|
Specially when you rename packages for no reason, right? ;-)
"david.lloyd(a)jboss.com" wrote :
| Standing the test of time is no test at all! What kind of argument is that. Just because someone didn't rewrite something for 4 years doesn't mean it's not crap. And there are many coders here whose "quickly coded crap" I would take over any multi-year-old library in a heartbeat.
|
Again, what kind of crap are you using?
I'm not saying you're completely wrong.
But in this case - as again my use-case proves it -
I would never take that re-invented "reflection abstraction + resource lookup abstraction" over existing impls.
"david.lloyd(a)jboss.com" wrote :
| We're here to solve problems, not worship old ineffective solutions.
You don't sound convincing, specially with all the negative comments about ext code.
Looks like you're more into re-writing things than solving real problems.
The world is not perfect, the code is not perfect,
but at least the code is open sourced, hence you can fix it. ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261321#4261321
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261321
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by david.lloyd＠jboss.com
"alesj" wrote : "david.lloyd(a)jboss.com" wrote : So we have to index all of them (unless there is some hint from the user that scanning is not necessary for a class or package or whatever)
| |
| Yes.
| The restriction mechanism should be plugable,
| and the one's I can think of right now are:
| * OSGi manifest export header
| * jboss-classloading.xml capabilities
|
Far simpler than designing a plugin mechanism for restrictions is to simplify the API so that you just give it the input streams of classes you want to index. Simplfying the API is usually preferable to adding an abstraction.
"alesj" wrote : "david.lloyd(a)jboss.com" wrote :
| | and remember (sans-classloading) where annotations are located, and the relationships between classes, so that we can find all classes and subclasses with certain annotations without actually loading any classes.
| This sounds interesting, but what's the easiest way to achieve this?
| I guess Javassist knows how to handle this.
| How hard would it be to add this to Reflect ...
|
| But is this really necessary?
| This should be done by tool anyway,
| depending on explicitly provided dependencies (mvn, ant, ...),
| so it should be easy to include all of the needed jars to make it run under UCL.
|
The specifications for many of our components (like EJB 3.1) tell us that we can't rely on this, or at least that's my understanding from the developer meeting when we decided we had to do it this way.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261305#4261305
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261305
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by david.lloyd＠jboss.com
"alesj" wrote : "david.lloyd(a)jboss.com" wrote : So - we are taking a small project, adding dependencies and making it more complex?
| |
| Why is adding dependecies making it more complex?
| It's exactly the opposite - less code to maintain.
|
Wrong. Because you end up contorting your code to match the use-case of the dependency, rather than the use case you're trying to achieve, causing ineffective code to become further entrenched, and making it even harder to fix later. VFS being one great example. Many projects relied on VFS because it is written for a particular use case. However, it just happened to be completely wrong. Now fixing it is a huge undertaking.
"alesj" wrote : "david.lloyd(a)jboss.com" wrote :
| | Adding dependencies is a bad idea. Projects should as a rule have the minimum number of runtime dependencies possible. Having lots of dependencies just makes it harder to refactor later. If you have a large web of dependencies between a set of projects, that's a big indicator that they ought to be one big project anyway, or at least split up differently.
| |
| Again nonsense.
| Refactoring is extremely easy if you have an external thing that does things for you.
|
Refactoring code is easy. Refactoring semantics is really difficult (see VFS again).
"alesj" wrote : In most cases those ext libs have stand the test of time,
| so they are much better then the crap you quickly code yourself.
| And the nicest things about all the pieces in my version of Papaki is that we control them all,
| meaning it's easy to create any missing feature or fix/extend an existing one.
|
Standing the test of time is no test at all! What kind of argument is that. Just because someone didn't rewrite something for 4 years doesn't mean it's not crap. And there are many coders here whose "quickly coded crap" I would take over any multi-year-old library in a heartbeat. We're here to solve problems, not worship old ineffective solutions.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261304#4261304
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261304
16 years, 5 months
[Embedded JBoss Development] - Re: embedded and bootsrap dependencies
by ALRubinger
To the point of the Bootstrap API being used for configuration and deployment, Emanuel and I discussed a bunch in #jboss-dev:
"#jboss-dev@Freenode" wrote : emuckenhuber: Still here?
| ALR: yes
| emuckenhuber: I remember why I didn't give Embedded its own API
| Because I'd essentially be either duplicating the AS Bootstrap or leaking it.
| emuckenhuber: End user needs to start/stop/config
| ALR: with config you mean the ServerConfig thingy ?
| emuckenhuber: Yep.
| ALR: yes, but this is currently based on system properties and should be mostly handled by the domain model in future - so i'm not sure how much of configuration part we can reuse for AS6
| emuckenhuber: Ideally very little.
| emuckenhuber: IMHO the sysprop approach is a way of circumventing a proper API
| emuckenhuber: Another thing we can consider: Plug through with the current model as we have it, and revisit config for AS6.
| emuckenhuber: Where we provide a hook into the unified domain model.
| emuckenhuber: And bootstrap>PS becomes integrated.
| Then we can draw a line. Bootstrap starts/stops a server. Configutation is some runtime model which is exposed by a real "Server". The Server *has* a bootstrap, *has* a PS domain config, *has* deployment hooks....
| And we piece together a full view via composition
| ALR: we can also do that later if you prefer
| ALR: it's just that i noticed that this will change in future
| ALR, emuckenhuber: composition is important
| emuckenhuber: I think so. Because we can still move forward with what we have in the current model. In the future I'll def want to make PS a first-class citizen here.
| But a lot of those hooks aren't yet available.
| And major version changes ie 5 to 6, I like to use as an opportunity to break down walls and build the cleanest thing we can rather than support components across major versions.
| ALR: yes that was at least the plan, i just can tell that profileservice nor bootstrap will depend on each other so far
| emuckenhuber: Cool, I'll make some notes of the discussion on the post
So the conclusion there is that the Embedded API will remain an extension of the bootstrap and we'll revisit at 6. The approach there may be:
Embedded Server delegates start/stop to Bootstrap, Deployment to TMPDPL, and configuration to PS. All composed together and behind locked SPIs.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261299#4261299
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261299
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by alesj
"david.lloyd(a)jboss.com" wrote : So - we are taking a small project, adding dependencies and making it more complex?
|
Why is adding dependecies making it more complex?
It's exactly the opposite - less code to maintain.
"david.lloyd(a)jboss.com" wrote :
| Adding dependencies is a bad idea. Projects should as a rule have the minimum number of runtime dependencies possible. Having lots of dependencies just makes it harder to refactor later. If you have a large web of dependencies between a set of projects, that's a big indicator that they ought to be one big project anyway, or at least split up differently.
|
Again nonsense.
Refactoring is extremely easy if you have an external thing that does things for you.
See my previous e.g.: "e.g. if you wanna add a restriction check"
In most cases those ext libs have stand the test of time,
so they are much better then the crap you quickly code yourself.
And the nicest things about all the pieces in my version of Papaki is that we control them all,
meaning it's easy to create any missing feature or fix/extend an existing one.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261295#4261295
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261295
16 years, 5 months
[JBoss ESB Development] - Re: SAML Token Support
by Kevin.Conner＠jboss.com
"anil.saldhana(a)jboss.com" wrote : I think that strategy is correct.
Sorry, but I disagree :)
"anil.saldhana(a)jboss.com" wrote : Validation has to happen through pluggable login modules. Toward this, the STS login module seems appropriate.
agreed.
"anil.saldhana(a)jboss.com" wrote : When the ESB layer has to generate SAML tokens, it needs to contact the STS. Hence it needs some integration logic (satisfied by the STS Action).
But it shouldn't be, if I understand things correctly. It should still be handled through the JAAS layer.
"anil.saldhana(a)jboss.com" wrote : I am assuming that the token generation happens before the ESB layer is called. Once an entity gets hold of the token, the ESB call is made with the token. Now on the ESB side, the login module is fielded to validate.
This action is within the ESB itself, directly linked to the SAML implementation. I want us to leverage the normal JAAS mechanisms.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261289#4261289
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261289
16 years, 5 months